Nordic "nRF52840 Dongle" Support

Posted on
of 6
/ 6
Last Next
  • Hmm - just tried here on the nRF52840DK - I can connect via serial and it's responsive. Then I can do USB.setConsole() and can program it over USB (looks like auto-switching isn't implemented).

    For Bluetooth it looks like it doesn't specify a BLE name, but I can connect using the CLI and that all seems to work as well.

    So I think it must be related to something on the dongle.

  • @urish I've had a go at compiling this but I've hit a wall and was wondering if you remember whether there was something extra that you did to get it to compile? I grabbed that branch from the repo, copied all of SDK_15.0.0 into targetlibs/nrf5x_15, copied all of the micro-ecc repository into the external/micro-ecc folder and then ran make clean && BOARD=NRF52840DK RELEASE=1 make. I'm running into this:

    /tmp/ccwJqUDl.ltrans0.ltrans.o: In function `nrf_drv_uart_tx':
    /home/steven/projects/Espruino-NRF52840/­targetlibs/nrf5x_15/integration/nrfx/leg­acy/nrf_drv_uart.h:516: undefined reference to `nrfx_uarte_tx'
    /tmp/ccwJqUDl.ltrans0.ltrans.o: In function `nrf_drv_uart_tx_abort':
    /home/steven/projects/Espruino-NRF52840/­targetlibs/nrf5x_15/integration/nrfx/leg­acy/nrf_drv_uart.h:549: undefined reference to `nrfx_uarte_tx_abort'
    /tmp/ccwJqUDl.ltrans9.ltrans.o: In function `nrf_drv_uart_uninit.constprop.241':
    /home/steven/projects/Espruino-NRF52840/­targetlibs/nrf5x_15/integration/nrfx/leg­acy/nrf_drv_uart.h:466: undefined reference to `nrfx_uarte_uninit'
    /tmp/ccwJqUDl.ltrans9.ltrans.o: In function `nrf_drv_uart_rx.constprop.202':
    /home/steven/projects/Espruino-NRF52840/­targetlibs/nrf5x_15/integration/nrfx/leg­acy/nrf_drv_uart.h:565: undefined reference to `nrfx_uarte_rx'
    /tmp/ccwJqUDl.ltrans9.ltrans.o: In function `nrf_drv_uart_init':
    /home/steven/projects/Espruino-NRF52840/­targetlibs/nrf5x_15/integration/nrfx/leg­acy/nrf_drv_uart.c:124: undefined reference to `nrfx_uarte_init'
    collect2: error: ld returned 1 exit status
    make/targets/ARM.make:2: recipe for target 'espruino_1v99_nrf52840.elf' failed
    make: *** [espruino_1v99_nrf52840.elf] Error 1

    Which isn't making sense as sdk_config.h has this:

    [#define](­ch/?q=%23define) NRFX_UARTE_ENABLED 0
    [#define](­ch/?q=%23define) NRFX_UARTE0_ENABLED 0
  • Tossing "#define NRFX_UARTE_ENABLED 0" into nrf_drv_uart.h seems to have got it working. Probably not the best way of dealing with it, but I haven't managed to narrow down where it should be...

  • Interesting. I've loaded this onto a Particle Xenon to give the nrf52840 a spin (gave up on writing stuff for it in C. Nothing wrong with the Particle stuff, I've just been spoiled by Espruino :P). I can connect via serial and use the console, then I can switch it over to USB and use it there. However, I'm also getting the lines of:

    ><- Serial1
    ><- Serial1
    ><- Serial1

    when trying the bluetooth UART. If I switch to USB, then try to connect via bluetooth, I get this instead:

    ><- USB
    ><- USB
    ><- USB

    I'm connecting via the Bluefruit app on Android. Having some issues getting the espruino cli talking to it at the moment, the noble module seems to have some bugs but isn't being maintained any more.

  • jsiSetConsoleDevice was only being called once, so it looked like it's something to do with Espruino->Bluetooth rather than something weird happening with the serial or USB ports. Figured it was a buffer not being cleared somewhere so I scanned through likely files until I found a candidate. Changed this in targets/nrf5x/bluetooth.c and it came good:

    [#if](­q=%23if) NRF_SD_BLE_API_VERSION>5
        uint32_t err_code = ble_nus_data_send(&m_nus, nusTxBuf, &nuxTxBufLength, m_peripheral_conn_handle);
        if (err_code == NRF_SUCCESS) nuxTxBufLength=0; //<- added this line
    [#elif](­/?q=%23elif) NRF_SD_BLE_API_VERSION<5
        uint32_t err_code = ble_nus_string_send(&m_nus, nusTxBuf, nuxTxBufLength);
        if (err_code == NRF_SUCCESS) nuxTxBufLength=0; // everything sent Ok
  • Nice - thanks! That's a great spot. Do you want to add a PR for that change, or shall I pull it in?

  • I'll put it in when I get home. I'm not really sure about the "uarte" issue though, I don't know if the change I made should be somewhere else or should be altogether different. (I'm pretty sure it shouldn't be in the SDK where I have done it though...)

  • I actually have the build working here, so I'm not sure what's different (I just pushed some changes that bring the branch up to date I hope). I'd have thought it was the targetlibs/nrf5x_15/nrf52_config/ folder but as far as I can see that's all up to date.

    @urish was there anything you remember having to change?

    There are some patches to do with the NFC libraries in targetlibs/nrf5x_15/patches but I don't think they target UART.

  • Actually, just merged into Master

  • Alright, thanks, I'll have a go with a fresh download and see how it goes.

  • It's happy now that it's merged. 👍

  • @Gordon I don't remember too much, but I will give it another go now and update shortly!

  • Update: it works well on nRF52840DK, but I had to follow @the1laz steps first:

    cd targetlibs/nrf5x_15/
    mv nRF5_SDK_15.0.0_a53641a/* .
    rm -rf nRF5_SDK_15.0.0_a53641a
    git apply patches/*
    rm -rf external/micro-ecc
    cp -Rp ../nrf5x_12/external/micro-ecc external/micro-ecc
    sed -i '/#include <nrfx\.h>/a # define NRFX_UARTE_ENABLED 0' integration/nrfx/legacy/nrf_drv_uart.h

    and then compile:

    make -DBOARD=NRF52840DK

    The firmware seems functional, with one caveat - it won't advertise the board name nor the UART service, making it unconnectable from Espruino Web IDE. After patching the Web IDE to use the acceptAllDevices options I was able to connect to it from the IDE as well.

  • Update: seems like commenting out this line solves the advertising issue. Calling sd_ble_gap_adv_set_configure with 0 for the second parameter seems to remove all the advertising data.

  • Interesting - thanks! Looks like it needs a bit of refactoring done so that maybe advertising_init and jsble_advertising_start use the same code

  • @Gordon would you like me to look into that and send a PR?

    On a different note, it seems like I am not being able to use any pins on the GPIO1 port. I have updated the board definition file to define ports up to D48, yet when digitalWriteing to D43 I have no indication from a connected LED. I have checked with another firmware, and the LED is driven by this pin correctly. Any ideas where to look for the culprit?

  • It'd be great if you could - thanks! Please could you try and make it so that advertising_init and jsble_advertising_start are merged on SDK13 as well? It's nice to try and keep the ifdef nightmare as small as possible :)

    For the IO, I'd check jshPinSetValue and similar stuff in jshardware.c:­b/master/targets/nrf5x/jshardware.c#L652­

    I guess there might be a different function to nrf_gpio_pin_write needed for GPIO1? If so, I'd add an 'if' based on pinInfo[pin].port and ensure that the port gets set correctly in the file.

  • So far, I learned that I can poke the GPIO register to make it work:

    1. Set it to output - poke32(0x50000300+0x518, 1 << 11)
    2. Write 0 - poke32(0x50000300+0x50c, 1 << 11)
    3. Write 1 - poke32(0x50000300+0x508, 1 << 11)

    This works and blinks the LED. Thanks for the pointer - my test program (without Espruino) is able to write to this port using nrf_gpio_pin_write successfully (through with SDK 15.2). I will try to narrow it down and see why it doesn't work from within Espruino.

  • I managed to narrow it down by looking at the generated assembly code - it seems like for some reason, GPIO_COUNT is set to 1, thus causing the wrong branch to be taken in nrf_gpio_pin_port_decode() in nrf_gpio.h.

  • I found the culprit - targetlibs/nrf5x_15/modules/nrfx/mdk/nrf­.h contains the following:

    /* Redefine "old" too-generic name NRF52 to NRF52832_XXAA to keep backwards compatibility. */
    [#if](­q=%23if) defined (NRF52)
        [#ifndef](­ch/?q=%23ifndef) NRF52832_XXAA
            [#define](­ch/?q=%23define) NRF52832_XXAA

    This defines NRF52832_XXAA, and thus causing both nrf52832_peripherals.h and nrf52840_peripherals.h to be included, and then the fun begins...

    After commenting this out, I am finally able to use the GPIO1 pins. @gordon do you want me to add a new SDK patch and send a PR?

  • Thanks for tracking this down. I guess the alternative is to change all of Espruino defines away from NRF52, which would be a nightmare?

    Assuming there's no easy fix in Espruino, a patch for the SDK would be great.

    At some point I should modify to automatically download, uncompress and patch the SDK - which would make stuff like this much easier.

  • Agreed - PR on its way, along with some other fixes that are required for making GPIO1 work

  • Hi guys,
    Thanks for making this work on NRF52840; Espruino mostly works now with a MDBT50Q on my own board. However, when trying to save to flash with save() in the REPL, the console hangs on "Calculating Size...". I have tried erasing storage with require("Storage").eraseAll() without result:

    Uncaught InternalError: Timeout on jshFlashErasePage
     at line 1 col 29

    I'm using a copy of the board file and use J-LINK to flash the *.hex binary.

    Status quo is that I can run any code, use GPIO 1, but not save it and run from boot. Also "Save on send" does not work. It just hangs forever, until I press CTRL+C, which yields "Execution Interrupted". Sometimes I get a message "Got ?[255] expected ','" when pressing CTRL+C, and the REPL points to the }); at line 3 of the code below. In that case, it executes the LED trigger with setInterval, except for the setWatch function. Using 'dump()' gives then the same error message.

    The code that I try to upload:

    setWatch(function() {
        print("Button was pressed");
    }, BTN1, {repeat: true, edge:"rising", debounce:50});
    var on = false;
    setInterval(function() {
        on = !on;

    BTN1 is connected to GPIO1 (D36) and LED2 to D8. Serial1 is working, and connected to an external module. REPL over USB is not working, Bluetooth works without problems. Using Espruino 2v03.12.

    Any thoughts?

  • Hi @Gordon, how about a new generation of Espruino boards based on NRF52840? More ram, flash and ultra low powerwith ble integrated... 😎

  • Sounds like the addresses for the saved code area (in need tweaking - it's odd though as I was pretty sure I had it working on nRF52840.

    I've definitely been considering nRF52840 - although IMO users aren't really hitting any big issues with nRF52 that the 52840 would fix. USB would definitely be nice though!

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

Nordic "nRF52840 Dongle" Support

Posted by Avatar for Stev @Stev