-
I see there was a change to this file 9 days ago
jslex.c
Fix for issue with pretokenised code not creating correct text string…
9 days ago -
With modified make instructions from:
https://github.com/espruino/Espruino/blob/master/README_Building.md
EDIT: I didn't catch that the build instruction beneath the nRF52 heading was for the 832
Left here in case it provides a cluetargets/nrf5x/jshardware.c:1016:3: note: called from here nrf_delay_us((uint32_t)microsec); ^ python scripts/check_elf_size.py NRF52832DK espruino_2v08.220_nrf52832.elf Testing espruino_2v08.220_nrf52832.elf for NRF52832DK STORAGE: 442368 -> 483328 FS DATA: 411912 -> 411928 (16 bytes) CODE: 126976 -> 411928 (284468 bytes) Code area Fits before Storage Area arm-none-eabi-objcopy -O ihex espruino_2v08.220_nrf52832.elf espruino_2v08.220_nrf52832.hex Merging SoftDevice python scripts/hexmerge.py /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_12/components/softdevice/s132/hex/s132_nrf52_3.1.0_softdevice.hex espruino_2v08.220_nrf52832.app_hex -o espruino_2v08.220_nrf52832.hex rgc@DESKTOP-R7T0VUC:/mnt/c/Users/robin/Espruino$ ls app espruino_2v08.220_esp32.bin NRF_Bootloader.md benchmark espruino_2v08.220_esp32.elf README_Building.md boards espruino_2v08.220_esp32.tgz README_BuildProcess.md build espruino_2v08.220_nrf52832.app_hex README.md ChangeLog espruino_2v08.220_nrf52832.elf scripts CONTRIBUTING.md espruino_2v08.220_nrf52832.hex src CURRENT_BOARD.make espruino_esp32.bin targetlibs dist_licences.txt gcc-arm-none-eabi-8-2018-q4-major targets dist_readme.txt gen tests Dockerfile libs Vagrantfile Doxyfile LICENSE workspace.code-workspace doxygen make xtensa-esp32-elf esp-idf Makefile espruino misc rgc@DESKTOP-R7T0VUC:/mnt/c/Users/robin/Espruino$
Now I see the .elf and .hex files.But how do I move the generated .hex file to the local Windows10 file system in order to flash with esptool?
EDIT: 06:56pm CST
Windows stores in two locations:The 832 .hex file was created at:
C:\Users\robin\Espruino\espruino_2v08.220_nrf52832.hex
and VSCode uses:
C:\Users\robin\AppData\Local\Temp
So, when the 840 .hex file is generated, I expect it will be accessible using the FileManger from the above location.I was under the impression that output was stored in <user>/AppData/local but nothing there.
EDIT: 04:48pm CSTOops! That .hex is not the resultant output, but an intermediate 832 version. I'm seeking the 840 version which doesn't seem to get built
-
Sat 2021.09.25
Now this is interesting.
I closed the VSCode workspace and shut down VSCode. Relaunched.
Ran make clean followed by make clean && BOARD=NRF52840DK RELEASE=1 make
and now get a unique new error:
make: *** [libs/compression/heatshrink/heatshrink_encoder.o] Error 127rgc@DESKTOP-R7T0VUC:/mnt/c/Users/robin/Espruino$ make clean Cleaning targets rgc@DESKTOP-R7T0VUC:/mnt/c/Users/robin/Espruino$ make clean && BOARD=NRF52840DK RELEASE=1 make Cleaning targets Generating platform configs Generating pin info Generating JS wrappers WRAPPERSOURCES = src/jswrap_array.c src/jswrap_arraybuffer.c src/jswrap_dataview.c src/jswrap_date.c src/jswrap_error.c src/jswrap_espruino.c src/jswrap_flash.c src/jswrap_functions.c src/jswrap_interactive.c src/jswrap_io.c src/jswrap_json.c src/jswrap_modules.c src/jswrap_pin.c src/jswrap_number.c src/jswrap_object.c src/jswrap_onewire.c src/jswrap_pipe.c src/jswrap_process.c src/jswrap_promise.c src/jswrap_regexp.c src/jswrap_serial.c src/jswrap_storage.c src/jswrap_spi_i2c.c src/jswrap_stream.c src/jswrap_string.c src/jswrap_waveform.c libs/compression/jswrap_heatshrink.c libs/math/jswrap_math.c libs/graphics/jswrap_graphics.c libs/network/jswrap_net.c libs/network/http/jswrap_http.c libs/network/js/jswrap_jsnetwork.c libs/bluetooth/jswrap_bluetooth.c libs/neopixel/jswrap_neopixel.c DEFINES = -DGIT_COMMIT=8c51e53 -DNO_ASSERT -DRELEASE -DBUILDNUMBER="220" -DNRF52840DK -DCONFIG_GPIO_AS_PINRESET -DBOARD_PCA10056 -DNRF_USB=1 -DUSB -DNEOPIXEL_SCK_PIN=22 -DNEOPIXEL_LRCK_PIN=23 -DUSE_DEBUGGER -DUSE_TAB_COMPLETE -DUSE_HEATSHRINK -DUSE_MATH -DUSE_GRAPHICS -DUSE_NET -DUSE_NETWORK_JS -DBLUETOOTH -DUSE_NEOPIXEL -DS140 -DNRF_SD_BLE_API_VERSION=6 -D__HEAP_SIZE=0 -DBLE_STACK_SUPPORT_REQD -DSWI_DISABLE0 -DSOFTDEVICE_PRESENT -DFLOAT_ABI_HARD -DNRF52_SERIES -DNRF52840_XXAA -DNRF52840 -DNRF5X -DNRF5X_SDK_15 -DUSE_APP_CONFIG -DARM -DLINK_TIME_OPTIMISATION -DEMBEDDED CC libs/compression/heatshrink/heatshrink_encoder.o make: arm-none-eabi-gcc: Command not found Makefile:797: recipe for target 'libs/compression/heatshrink/heatshrink_encoder.o' failed make: *** [libs/compression/heatshrink/heatshrink_encoder.o] Error 127 make: *** Waiting for unfinished jobs.... make: *** wait: No child processes. Stop. rgc@DESKTOP-R7T0VUC:/mnt/c/Users/robin/Espruino$ -
Wow, and this sequence worked:
make clean make BOARD=NRF52840DK makesrc/jsutils.c:374:3: note: called from here NVIC_SystemReset(); ^ /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/toolchain/cmsis/include/core_cm4.h:1790:22: warning: inlining failed in call to 'NVIC_SystemReset': call is unlikely and code size would grow [-Winline] __STATIC_INLINE void NVIC_SystemReset(void) ^ src/jsutils.c:374:3: note: called from here NVIC_SystemReset(); ^ python scripts/check_elf_size.py NRF52840DK espruino_2v08.220_nrf52840.elf Testing espruino_2v08.220_nrf52840.elf for NRF52840DK STORAGE: 966656 -> 1007616 FS DATA: 492980 -> 493000 (20 bytes) CODE: 155648 -> 493000 (336136 bytes) Code area Fits before Storage Area arm-none-eabi-objcopy -O ihex espruino_2v08.220_nrf52840.elf espruino_2v08.220_nrf52840.hex Merging SoftDevice python scripts/hexmerge.py /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/softdevice/s140/hex/s140_nrf52_6.0.0_softdevice.hex espruino_2v08.220_nrf52840.app_hex -o espruino_2v08.220_nrf52840.hex rgc@DESKTOP-R7T0VUC:/mnt/c/Users/robin/Espruino$Fianlly, espruino_2v08.220_nrf52840.elf and espruino_2v08.220_nrf52840.hex get built!
I have no explanation other than I removed the RELEASE=1 part and cleaned in separate steps:
make clean make BOARD=NRF52840DK makevs
make clean && BOARD=NRF52840DK RELEASE=1 make -
Sat 2021.09.25 - 07:54pm CST
Have spent 12 hours on this, and it gets even more perplexing:
I have built this on three separate attempts to see if I could uncover a cause and the number of bytes for the same file build changes: (I only ran the provision.sh script once prior)
This shouldn't happen, should it????
While the storage value is consistent: STORAGE: 966656 -> 1007616 the data and code sections change:
FS DATA: 492980 -> 493000 (20 bytes) CODE: 155648 -> 493000 (336136 bytes) FS DATA: 452756 -> 452776 (20 bytes) CODE: 155648 -> 452776 (296248 bytes) FS DATA: 494012 -> 494032 (20 bytes) CODE: 155648 -> 494032 (337168 bytes)Could this anomaly reveal a cause for the build errors?
Will try flashing tomorrow.Shutting down for the evening to now enjoy both a bourbon and a nice 6yr rye. . . .
-
Sun 2021.09.26
While looking over the provision.sh file
L140 echo Installing python and pip sudo DEBIAN_FRONTEND=noninteractive apt-get install -qq -y python python-pipWhat version of Python need be installed?
I have a user installed version 3.7 that runs from Windows:
Note the version date(s) that didn't seemed to have gotten updated by their release team
C:\WINDOWS\system32>python Python 3.7.4 (tags/v3.7.4:e09359112e, Jul 8 2019, 19:29:22) [MSC v.1916 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>>VSCode somhow loads a version 2.7 that isn't (intentionally) installed on this PC - Maybe inside WSL?
rgc@DESKTOP-R7T0VUC:/mnt/c/Users/robin/Espruino$ python Python 2.7.12 (default, Aug 22 2019, 16:36:40) [GCC 5.4.0 20160609] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>>Could this version be part of the issue?
Could the dynamic loading of Python during the build have some sort of delay that blocks the scripts from executing timely? -
Sun 2021.09.26
After re-reading these threads, It appears from the errors that make is more likely the culprit.
This notation might explain why after several make clean cycles,
https://stackoverflow.com/questions/61684562/need-to-run-make-twice-after-make-clean
See green checked item descriptionI looked over NRF5X.make but don't see any commonalities there.
-
Thr 2021.09.30
re: post #5 'Wow, and this sequence worked:'
re: post #8 above
re: post #15 success at Firmware build for PICO fails - make: ***Well that was short lived.
After several days of trial and error, I thought I had a work around using two separate 'make clean' steps.While that seemed to work, it is only around three out of five attempts. I have even tried switching the provision.sh targets, cleaning, build, then switching back to the desired target with limited success.
Q: Is it necessary to run the provision.sh script each and every time a build is desired? (?no?)
I've even verified after each clean step the the src and gen folders are gone of .o compiled files before I start the build.I'm wondering if there is some kind of file locking hiccup within Windows10 that blocks the ability of the make utility from writing the file timely, as the errors are never consistent. I'd like to isolate/eliminate whether it might be the file system.
Q: Does anyone know of a trick to add a small delay between each .o file compile with make or gcc to slow down the build? -
try to have the source files inside wsl, I see paths like /mnt/c/Users/robin/Espruino this is asking for trouble due to differencies in filename case sensitivity and windows file timestamps, see also https://docs.microsoft.com/en-us/windows/wsl/filesystems (and someone having similar issues here )
since you also installed random stuff on windows side of things I'd try also to disable windows-wsl interoperability so you know only linux native stuff is run for 'make', 'arm-none-eabi-gcc' etc, not mixed windows/linux. This is configured in /etc/wsl.conf
$ cat /etc/wsl.conf # after change run in powershell Restart-Service LxssManager [interop] enabled=false appendWindowsPath=falseyou can see if you have windows path prepended by running
echo $PATHyou should see only linux paths there. The easiest temporary fix for this is also to just change your path variable - before runningmaketry something likeexport PATH=/home/robin/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/binand exlude paths pointing to windows - /mnt/c/whatever -
Fri 2021.10.01
Install comment: I thought I was installing the files within WSL using the git link to clone the respository from within the terminal window. I'll go back over those steps again, to validate.
A lot to digest there, but I believe you have hit the nail on the head with your quick eye and analysis regarding the case sensitivity.
Thank you @fanoush as with that quick response, will give me a good head start on checking that all out this weekend starting early Saturday morning. I'll have my work cut out for me!!
-
Ok, I just spotted your other post and your original issue I believe could be that you're building for Linux natively and are then switching to a different device and are not cleaning the build:
# building for linux make clean && make # get t he stuff you need for other builds source scripts/provision.sh ESPRUINOWIFI # YOU NEED 'make clean' IN HERE <====================== BOARD=ESPRUINOWIFI makeIs it necessary to run the provision.sh script each and every time a build is desired?
If you close the terminal window between times then yes.
provision.shsets up the environment variables for that terminal session, so if you close it, it you need to run that again.Obviously you can do things to make it permanent but then if
provision.shchanges you get into all kinds of pain - so I figure it's best for the casual developer to just useprovision.sheach time -
Wed 2021.10.06
'your original issue I believe could be that you're building for Linux natively and are then switching to a different device and are not cleaning the build:'
Thank you for the analysis @Gordon.
'could be that you're building for Linux natively'
'then switching to a different device'I'm not entirely sure I'm performing the task referenced here. Just to be clear, I'm not intentionally changing the device for the nRF52840 build.
Please (anyone) correct me if my understanding is incorrect, but all my commands are being entered inside the terminal window that is launched from the VSCode menu. My belief (as I'm sure I'm not fully understanding) is that WSL is the binding that allows a user to enter/execute Unix like commands on a DOS based PC. Kinda like a Unix virtual machine running inside it's own frame. (not sure if 'window' is a good choice of words for Unix) So, I don't believe I need a separate terminal window like the Putty app, just using the one VSCode provides.
When you explain 'building for Linux natively' and should that mean creating the .hex file and then 'switching to a different device' is something I'm not (intentionally) doing.
I was however during frantic now what the expletive do I do now sessions, did try combinations of clean and switching the provision scripts as that sequence did a couple of times seem to allow me to make progress. (errors changed and were never repeatable)
The insight @fanoush observed seems to be what is happening based on my file write delay hunch.
Over the weekend, I'll try that post #10 sequence with the additional step and make (no pun - okay pun) sure I repeat that exact sequence each time.Also, the additional J-Link adapter board arrived today so I'll have a chance to attempt the debug suggestions @fanoush provided, once I locate a brief operations tutorial and pin-out for the SEGGER board. I'll also play with the PATH environment var within the terminal window as my belief is that the update of nRFConnect has done somethong within the registry that when I launch a cmd window, VSCode and nRFConnect from a clean boot, the Win10 PATH environment var starts duplicating itself, running out of space, thereby corrupting it and blocking apps/processes from running cleanly. If I can get to the bottom of
that, I'll post results. Leaving that here in case others stumble across similar issues as in this thread. -
Here, you are building a file designed to run on your PC, not a microcontroller. It'll be a 64 bit x86 build:
make clean && makeHere you're building a binary file to run on the Espruino Wifi's ARM, but because you didn't clear the build, some files will have been built for the wrong platform:
BOARD=ESPRUINOWIFI makeYou also need to build with
RELEASE=1. It seems there are pretty clear instructions at https://github.com/espruino/Espruino/blob/master/README_Building.md#for-stm32-boards-incl-espruino-boardSo if you run the command listed there:
make clean && BOARD=ESPRUINOWIFI RELEASE=1 makeyou may have more success
fanoush
Gordon-
Post a reply
About
nRF52840DK build error: src/jslex.o make: *** [espruino_2v08.220_nrf52840.elf] Error 1
Posted by
@Robin
Sat 2021.09.25
My original continuation is actually a unique new error specific to the DK nRF52840DK
Progress made after successful install of SDK15, but a new error surfaced:
make: *** [espruino_2v08.220_nrf52840.elf] Error 1