nRF52840DK build error: src/jslex.o make: *** [espruino_2v08.220_nrf52840.elf] Error 1

[espruino-discuss]

Posted at 2021-09-25 by Robin

Sat 2021.09.25

My original continuation is actually a unique new error specific to the DK nRF52840DK

post #21 WebIDE locks up while loading require("neopixel")

Progress made after successful install of SDK15, but a new error surfaced: make: *** [espruino_2v08.220_nrf52840.elf] Error 1

``` CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/libraries/atomic/nrf_atomic.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/libraries/atomic_flags/nrf_atflags.oCC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/ble/ble_link_ctx_manager/ble_link_ctx_manager.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/libraries/util/app_error_handler_gcc.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/ble/peer_manager/pm_mutex.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/ble/common/ble_advdata.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/ble/common/ble_conn_params.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/ble/common/ble_srv_common.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/ble/common/ble_conn_state.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/ble/ble_services/ble_nus/ble_nus.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/ble/peer_manager/peer_manager.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/ble/peer_manager/peer_id.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/ble/peer_manager/peer_database.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/ble/peer_manager/peer_data_storage.oCC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/ble/peer_manager/pm_buffer.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/ble/peer_manager/id_manager.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/ble/peer_manager/security_manager.o targetlibs/nrf5x_15/components/ble/peer_manager/pm_buffer.c: In function 'pm_buffer_block_acquire': targetlibs/nrf5x_15/components/ble/peer_manager/pm_buffer.c:104:46: warning: comparison of integer expressions of different signedness: 'int' and 'uint32_t' {aka 'long unsigned int'} [-Wsign-compare] if ((i - first_locked_mutex + 1) == n_blocks) ^~ CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/ble/peer_manager/security_dispatcher.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/ble/peer_manager/gatt_cache_manager.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/ble/peer_manager/gatts_cache_manager.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/libraries/timer/app_timer.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/libraries/fds/fds.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/libraries/queue/nrf_queue.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/libraries/util/app_util_platform.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/libraries/util/sdk_mapped_flags.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/libraries/util/app_error.o targetlibs/nrf5x_15/components/libraries/fds/fds.c: In function 'write_execute': targetlibs/nrf5x_15/components/libraries/fds/fds.c:1237:16: warning: this statement may fall through [-Wimplicit-fallthrough=] if (!record_find_by_desc(&desc, &page)) ^ targetlibs/nrf5x_15/components/libraries/fds/fds.c:1245:9: note: here case FDS_OP_WRITE_HEADER_BEGIN: ^~~~ CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/libraries/util/nrf_assert.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/softdevice/common/nrf_sdh.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/softdevice/common/nrf_sdh_ble.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/softdevice/common/nrf_sdh_soc.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/libraries/experimental_section_vars/nrf_section_iter.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/libraries/fstorage/nrf_fstorage.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/libraries/fstorage/nrf_fstorage_sd.oCC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/libraries/atomic_fifo/nrf_atfifo.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/libraries/strerror/nrf_strerror.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/libraries/balloc/nrf_balloc.o LD espruino_2v08.220_nrf52840.elf src/jslex.o: file not recognized: file format not recognized collect2: error: ld returned 1 exit status make/targets/ARM.make:2: recipe for target 'espruino_2v08.220_nrf52840.elf' failed make: *** [espruino_2v08.220_nrf52840.elf] Error 1 rgc@DESKTOP-R7T0VUC:/mnt/c/Users/robin/Espruino$ ```

[espruino-discuss]

Posted at 2021-09-25 by Robin

I see there was a change to this file 9 days ago

https://github.com/espruino/Espruino/tree/master/src

jslex.c
Fix for issue with pretokenised code not creating correct text string…
9 days ago

---

Posted at 2021-09-25 by Robin

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 clue

targets/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 CST*

Oops! 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

---

Posted at 2021-09-25 by Robin

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 127

rgc@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$

---

Posted at 2021-09-26 by Robin

Wow, and this sequence worked:

make clean make

BOARD=NRF52840DK make

src/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 make

vs

make clean && BOARD=NRF52840DK RELEASE=1 make

---

Posted at 2021-09-26 by Robin

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. . . .

---

Posted at 2021-09-26 by Robin

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-pip

What 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?

---

Posted at 2021-09-26 by Robin

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 description

I looked over NRF5X.make but don't see any commonalities there.

---

Posted at 2021-10-01 by Robin

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?

---

Posted at 2021-10-01 by @fanoush

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=false

you can see if you have windows path prepended by running echo $PATH you should see only linux paths there. The easiest temporary fix for this is also to just change your path variable - before running make try something like export PATH=/home/robin/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin and exlude paths pointing to windows - /mnt/c/whatever

---

Posted at 2021-10-02 by Robin

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!!

---

Posted at 2021-10-06 by @gfwilliams

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 make

Is 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.sh sets 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.sh changes you get into all kinds of pain - so I figure it's best for the casual developer to just use provision.sh each time

---

Posted at 2021-10-07 by Robin

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 @gfwilliams.

'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.

---

Posted at 2021-10-07 by @gfwilliams

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 && make

Here 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 make

You 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-board

So if you run the command listed there:

make clean && BOARD=ESPRUINOWIFI RELEASE=1 make

you may have more success