• 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/n­rf5x_15/components/libraries/atomic/nrf_­atomic.o
    CC /mnt/c/Users/robin/Espruino/targetlibs/n­rf5x_15/components/libraries/atomic_flag­s/nrf_atflags.oCC /mnt/c/Users/robin/Espruino/targetlibs/n­rf5x_15/components/ble/ble_link_ctx_mana­ger/ble_link_ctx_manager.o
    CC /mnt/c/Users/robin/Espruino/targetlibs/n­rf5x_15/components/libraries/util/app_er­ror_handler_gcc.o
    CC /mnt/c/Users/robin/Espruino/targetlibs/n­rf5x_15/components/ble/peer_manager/pm_m­utex.o
    CC /mnt/c/Users/robin/Espruino/targetlibs/n­rf5x_15/components/ble/common/ble_advdat­a.o
    CC /mnt/c/Users/robin/Espruino/targetlibs/n­rf5x_15/components/ble/common/ble_conn_p­arams.o
    CC /mnt/c/Users/robin/Espruino/targetlibs/n­rf5x_15/components/ble/common/ble_srv_co­mmon.o
    CC /mnt/c/Users/robin/Espruino/targetlibs/n­rf5x_15/components/ble/common/ble_conn_s­tate.o
    CC /mnt/c/Users/robin/Espruino/targetlibs/n­rf5x_15/components/ble/ble_services/ble_­nus/ble_nus.o
    CC /mnt/c/Users/robin/Espruino/targetlibs/n­rf5x_15/components/ble/peer_manager/peer­_manager.o
    CC /mnt/c/Users/robin/Espruino/targetlibs/n­rf5x_15/components/ble/peer_manager/peer­_id.o
    CC /mnt/c/Users/robin/Espruino/targetlibs/n­rf5x_15/components/ble/peer_manager/peer­_database.o
    CC /mnt/c/Users/robin/Espruino/targetlibs/n­rf5x_15/components/ble/peer_manager/peer­_data_storage.oCC /mnt/c/Users/robin/Espruino/targetlibs/n­rf5x_15/components/ble/peer_manager/pm_b­uffer.o
    CC /mnt/c/Users/robin/Espruino/targetlibs/n­rf5x_15/components/ble/peer_manager/id_m­anager.o
    CC /mnt/c/Users/robin/Espruino/targetlibs/n­rf5x_15/components/ble/peer_manager/secu­rity_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/n­rf5x_15/components/ble/peer_manager/secu­rity_dispatcher.o
    CC /mnt/c/Users/robin/Espruino/targetlibs/n­rf5x_15/components/ble/peer_manager/gatt­_cache_manager.o
    CC /mnt/c/Users/robin/Espruino/targetlibs/n­rf5x_15/components/ble/peer_manager/gatt­s_cache_manager.o
    CC /mnt/c/Users/robin/Espruino/targetlibs/n­rf5x_15/components/libraries/timer/app_t­imer.o
    CC /mnt/c/Users/robin/Espruino/targetlibs/n­rf5x_15/components/libraries/fds/fds.o
    CC /mnt/c/Users/robin/Espruino/targetlibs/n­rf5x_15/components/libraries/queue/nrf_q­ueue.o
    CC /mnt/c/Users/robin/Espruino/targetlibs/n­rf5x_15/components/libraries/util/app_ut­il_platform.o
    CC /mnt/c/Users/robin/Espruino/targetlibs/n­rf5x_15/components/libraries/util/sdk_ma­pped_flags.o
    CC /mnt/c/Users/robin/Espruino/targetlibs/n­rf5x_15/components/libraries/util/app_er­ror.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/n­rf5x_15/components/libraries/util/nrf_as­sert.o
    CC /mnt/c/Users/robin/Espruino/targetlibs/n­rf5x_15/components/softdevice/common/nrf­_sdh.o
    CC /mnt/c/Users/robin/Espruino/targetlibs/n­rf5x_15/components/softdevice/common/nrf­_sdh_ble.o
    CC /mnt/c/Users/robin/Espruino/targetlibs/n­rf5x_15/components/softdevice/common/nrf­_sdh_soc.o
    CC /mnt/c/Users/robin/Espruino/targetlibs/n­rf5x_15/components/libraries/experimenta­l_section_vars/nrf_section_iter.o
    CC /mnt/c/Users/robin/Espruino/targetlibs/n­rf5x_15/components/libraries/fstorage/nr­f_fstorage.o
    CC /mnt/c/Users/robin/Espruino/targetlibs/n­rf5x_15/components/libraries/fstorage/nr­f_fstorage_sd.oCC /mnt/c/Users/robin/Espruino/targetlibs/n­rf5x_15/components/libraries/atomic_fifo­/nrf_atfifo.o
    CC /mnt/c/Users/robin/Espruino/targetlibs/n­rf5x_15/components/libraries/strerror/nr­f_strerror.o
    CC /mnt/c/Users/robin/Espruino/targetlibs/n­rf5x_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
  • I see there was a change to this file 9 days ago


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

  • With modified make instructions from:


    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
    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/n­rf5x_12/components/softdevice/s132/hex/s­132_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/E­spruino$ 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

    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:


    and VSCode uses:

    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

  • 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/E­spruino$ make clean
    Cleaning targets
    rgc@DESKTOP-R7T0VUC:/mnt/c/Users/robin/E­spruino$ 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
    CC libs/compression/heatshrink/heatshrink_e­ncoder.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.
  • Wow, and this sequence worked:

    make clean make
    BOARD=NRF52840DK make
    src/jsutils.c:374:3: note: called from here
    /mnt/c/Users/robin/Espruino/targetlibs/n­rf5x_15/components/toolchain/cmsis/inclu­de/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
    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/n­rf5x_15/components/softdevice/s140/hex/s­140_nrf52_6.0.0_softdevice.hex espruino_2v08.220_nrf52840.app_hex -o espruino_2v08.220_nrf52840.hex

    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


    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

          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

    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/E­spruino$ 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,

    See green checked item description

    I 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

    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/s­bin:/usr/local/bin:/usr/sbin:/usr/bin:/s­bin:/bin and 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 <======================

    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

  • 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 && 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:


    You also need to build with RELEASE=1. It seems there are pretty clear instructions at https://github.com/espruino/Espruino/blo­b/master/README_Building.md#for-stm32-bo­ards-incl-espruino-board

    So if you run the command listed there:

    make clean && BOARD=ESPRUINOWIFI RELEASE=1 make

    you may have more success

  • Post a reply
    • Bold
    • Italics
    • Link
    • Image
    • List
    • Quote
    • code
    • Preview

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

Posted by Avatar for Robin @Robin