Nordic "nRF52840 Dongle" Support #6870

espruino-discuss · 2025-02-12T16:55:09Z

espruino-discuss
Feb 12, 2025
Maintainer

Posted at 2018-07-26 by Stev

Hey,

just received a few of those "original" nRF Dongles today. Is there already support for those?

-Stev

espruino-discuss · 2025-02-12T16:55:12Z

espruino-discuss
Feb 12, 2025
Maintainer Author

Posted at 2018-07-26 by @gfwilliams

I'm afraid not. I've been looking into support for the nRF52840DK but realistically to work properly it needs to be running with SDK15, and I haven't managed to get that going at the moment.

They look like great little devices though, and extremely cheap too.

Posted at 2018-07-26 by Stev

They look like great little devices though, and extremely cheap too.

Well, I guess all the Nordic chips ask for this kind of cheap generic board designs, this one from Nordic themselves, so that will not go away. Still enough market for specific power/battery designs and special form factors as well as sensor/display combos.

Now that the 52s with this chip got USB support, too, I hoped to get Espruino's USB HID support running, though I haven't verified that they will support that via the dongle's USB contact pads...

Posted at 2018-07-26 by Stev

but realistically to work properly it needs to be running with SDK15

From the SDK downloads page it seems that the SDK from 12.2.0 up support the nRF52840.

So the keyword were "realistically" and "properly"?

Posted at 2018-07-27 by @gfwilliams

I hoped to get Espruino's USB HID support running

That's probably going to be a whole other chunk of work I'm afraid. You'll basically be starting from scratch as all of Espruino's USB HID code is STM32 specific.

So the keyword were "realistically" and "properly"?

As I understand it, USB only really became properly supported in 15 (I believe it was pretty flaky before). I did have a build for nRF52840 on SDK14 but USB never worked.

But I could be wrong - you're welcome to give it a try yourself.

Posted at 2018-07-27 by Stev

15’s release notes say something about production quality, also for USB, so lets hope they mean it.

For the HID part, I totally forgot about the STM specific implementation. Still, the 52840’s integrated USB is a pretty cool thing and makes that dongle so interesting.

I had a look at the HID examples yesterday but had troubles with flashing existing example hex’ and getting some if the tools to work. Seems I have to recompile using the full tool chain.

The dongle is brand new and the desktop integration might still need minor work/updating.

I‘ll post an update if I got something going Espruino-wise.

Posted at 2018-07-27 by user92372

Please do keep us updated, I have 2 of these little jewels arriving Wednesday.

Posted at 2018-07-28 by Stev

Better not count on an early. Got the native blinky example running..
Not sure, how much time I'll have on my hands in August. Intensely waiting for a rainy day for looking at the Espruino code :)

Posted at 2018-08-09 by @gfwilliams

Just to let you know I now have a build of Espruino running on SDK15 on the nRF52840, with preliminary USB support (you can move the console over to it and upload code \o/ ).

Posted at 2018-08-09 by user92372

Terrence here.
Wow, that is really good news. I have 2 of those little chips and eager to put them to use.

Posted at 2018-08-09 by Stev

Hooray, indeed, @gfwilliams

Though we got a new dog and I will never have time for anything again, I‘m afraid...

Had a look at the sources, though, last week after not having looked at it for a few years now, and am pretty happy with what Espruino has become and that it‘s well and alive. Great work.

Posted at 2018-09-13 by urish

Hi @gfwilliams,

Is the code for the nRF52840 + USB on GitHub? I tried to look for it in master, but couldn't seem to find any mention of nRF + USB...

Thx!

Posted at 2018-09-18 by @gfwilliams

It is now :) https://github.com/espruino/Espruino/tree/NRF52840

Posted at 2018-09-18 by urish

Thank you for that @gfwilliams! Does it still build for you?

I'm getting an error saying it can't find nrf.h, I suspect it could be looking in the wrong place or perhaps this file is missing in the nrf5x_15 sdk folder?

uri@JAY:/home/uri/espruino$ make BOARD=NRF52840DK RELEASE=1
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/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=0304abbc -DNO_ASSERT -DRELEASE -DBUILDNUMBER="154" -DCONFIG_GPIO_AS_PINRESET -DBOARD_PCA10056 -DNRF_USB=1 -DUSB -DUSE_DEBUGGER -DUSE_TAB_COMPLETE -DUSE_HEATSHRINK -DUSE_MATH -DUSE_GRAPHICS -DUSE_NET -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 -DNRF52840_XXAA -DNRF52840DK -DNRF52840 -DNRF5X -DNRF5X_SDK_15 -DARM -DLINK_TIME_OPTIMISATION -DEMBEDDED
CC libs/compression/heatshrink/heatshrink_encoder.o
CC libs/compression/heatshrink/heatshrink_decoder.o
CC libs/compression/compress_heatshrink.o
In file included from /mnt/c/P/espruino/src/jsutils.h:17:0,
                 from libs/compression/compress_heatshrink.c:15:
gen/platform_config.h:13:17: fatal error: nrf.h: No such file or directory
 #include "nrf.h"
                 ^
compilation terminated.
Makefile:768: recipe for target 'libs/compression/compress_heatshrink.o' failed
make: *** [libs/compression/compress_heatshrink.o] Error 1

Posted at 2018-09-19 by urish

Looking at .gitignore, it seems like most of the content of the nrf5x_15 folder is not present in git. Thus, I manually downloaded SDK 15 (as well as micro-ecc, under targetlibs/nrf5x_15/external/micro-ecc), so now the source code compiles, however the linker script is missing:

CC /home/uri/espruino/targetlibs/nrf5x_15/components/libraries/experimental_memobj/nrf_memobj.o
make: *** No rule to make target '/home/uri/espruino/targetlibs/nrf5x_15/nrf5x_linkers/linker_nrf52840_ble_espruino.ld', needed by 'espruino_1v99.154_nrf52840.elf'.  Stop.

Any pointers?

Posted at 2018-09-19 by @gfwilliams

try now :)

Posted at 2018-09-19 by urish

😍

It compiles!

When I upload the .hex file and run it on the chip, it doesn't seem to be showing up as a USB device, though it is connectable by BLE (even though it doesn't seem to advertise correctly). When I debug it in GDB, it seems to always stop inside jswrap_regexp routines, e.g.:

(gdb) monitor reset
(gdb) c
Continuing.
target not halted
target nrf52.cpu was not halted when resume was requested
^C
Program received signal SIGINT, Interrupt.
matchfound (txtIt=<optimized out>, info=...) at src/jswrap_regexp.c:57
57        jsvObjectSetChild(rmatch, "input", info.sourceStr);
(gdb)

Not sure if this is something wrong with my setup or it indeed is busy parsing regular expressions all the time for some reason. I will keep investigating - any pointers are appreciated!

Posted at 2018-09-19 by urish

Since the advertisement was broken, I went ahead and patched navigator.requestDevice so I could still connect to the device over BLE-UART using the Espruino Web IDE:

_originalRequestDevice = navigator.bluetooth.requestDevice;
navigator.bluetooth.requestDevice = function(p) { 
  delete p.filters;
  p.acceptAllDevices = true; 
  return _originalRequestDevice.call(this, p);
};

However, once connected, the device sends a single line endlessly, and does not seem to respond to any input:

<- Serial1
<- Serial1
<- Serial1
...

Any ideas what this might be?

Posted at 2018-09-20 by @gfwilliams

Hmm - not sure. What are you running it on? The 52840DK, or the dongle?

The board file was for the DK so perhaps there's something different in the pin mappings? <- Serial1 happens when the REPL moves to Serial1, which I guess it might do if USB dropped out? The code to swap REPL probably isn't designed for working with USB, Bluetooth and serial so it might choose the wrong one.

It's possible that the computer you're using keeps connecting & disconnecting on USB, which causes that?

Posted at 2018-09-20 by urish

It's running on the Dongle, I'll try to tinker with the pin mapping and see if that helps.

It doesn't seem the the USB serial port even show up on the Windows machine I'm connecting it to - it works in CircuitPython for the same dongle, though, so this probably has something to do with the configuration. Should I try switching to SDK 15.2.0 and see if that helps?

So far, I tried changing the pin mapping for the serial port and map RX/TX to unconnected pins, but it didn't make any difference. Also, tried switching the default console to EV_USBSERIAL, and now I'm getting an endless loop of <- USB when connecting through Bluetooth.

Posted at 2018-09-21 by @gfwilliams

Should I try switching to SDK 15.2.0 and see if that helps?

You could give it a go. Looks like I used SDK15 for my builds.

Honestly not sure what to suggest though - afraid I'm a bit too busy to help out with this at the moment

Posted at 2018-09-21 by urish

Sure, no worries! I'm already happy that we managed to get it to build and run on my board. Perhaps you could share one of the hex files that you have built so I will be able to test it and compare the results?

Posted at 2018-09-24 by @gfwilliams

Here's one I believe works - however I was using the 52840DK, not the Dongle - so I don't know if that changes things.

Attachments:

espruino_1v99.152_nrf52840.hex

Posted at 2018-09-25 by urish

Thank you!

Posted at 2018-09-26 by urish

Okay, the hex file you built is giving me a similar result:

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

I'm wondering why each line now has an extra > in front of it (there wasn't one in my version).

Anyway, getting Espruino to run on it is just a nice to have experiment for me at this stage, so if you are busy, this can definitely wait...

Posted at 2018-09-26 by @gfwilliams

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.

Posted at 2019-04-13 by the1laz

@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/legacy/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/legacy/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/legacy/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/legacy/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/legacy/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 NRFX_UARTE_ENABLED 0
#define NRFX_UARTE0_ENABLED 0

Posted at 2019-04-13 by the1laz

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

Posted at 2019-04-13 by the1laz

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.

Posted at 2019-04-14 by the1laz

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

Posted at 2019-04-15 by @gfwilliams

Nice - thanks! That's a great spot. Do you want to add a PR for that change, or shall I pull it in?

Posted at 2019-04-15 by the1laz

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

Posted at 2019-04-15 by @gfwilliams

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.

Posted at 2019-04-15 by @gfwilliams

Actually, just merged into Master

Posted at 2019-04-16 by the1laz

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

Posted at 2019-04-16 by the1laz

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

Posted at 2019-04-21 by urish

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

Posted at 2019-04-21 by urish

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

cd targetlibs/nrf5x_15/
wget https://developer.nordicsemi.com/nRF5_SDK/nRF5_SDK_v15.x.x/nRF5_SDK_15.0.0_a53641a.zip
unzip nRF5_SDK_15.0.0_a53641a.zip
mv nRF5_SDK_15.0.0_a53641a/* .
rm -rf nRF5_SDK_15.0.0_a53641a nRF5_SDK_15.0.0_a53641a.zip
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.

Posted at 2019-04-23 by urish

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.

Posted at 2019-04-23 by @gfwilliams

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

Posted at 2019-04-23 by urish

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

Posted at 2019-04-23 by @gfwilliams

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: https://github.com/espruino/Espruino/blob/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 BOARD.py file.

Posted at 2019-04-23 by urish

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

Set it to output - poke32(0x50000300+0x518, 1 << 11)
Write 0 - poke32(0x50000300+0x50c, 1 << 11)
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.

Posted at 2019-04-23 by urish

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.

Posted at 2019-04-23 by urish

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 defined (NRF52)
    #ifndef NRF52832_XXAA
        #define NRF52832_XXAA
    #endif
#endif

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?

Posted at 2019-04-23 by @gfwilliams

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 provision.sh to automatically download, uncompress and patch the SDK - which would make stuff like this much easier.

Posted at 2019-04-23 by urish

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

Posted at 2019-06-01 by Delano

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:

>require("Storage").eraseAll()
Uncaught InternalError: Timeout on jshFlashErasePage
 at line 1 col 29
require("Storage").eraseAll()
                            ^
>require("Storage").eraseAll()
=undefined

I'm using a copy of the NRF52840DK.py 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;
    LED2.write(on);
},50);

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?

Posted at 2019-06-01 by asez73

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

Posted at 2019-06-03 by @gfwilliams

Sounds like the addresses for the saved code area (in BOARD.py) 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!

Posted at 2019-06-03 by Delano

I think you are right @gfwilliams about the board.py configuration; will look into it a bit more.

IMHO the NRF52840 is indeed nice because of the dedicated USB, and e.g. Thread (IEEE 802.15.4 / 6LowPan based) protocol support. Also, it has a nice amount of GPIO for advanced set-ups :)

Posted at 2019-06-09 by tcpipchip

yes, think about and then we can port to NINA B3 now :)

Posted at 2019-06-09 by tcpipchip

But, is there some tip to compile to NRF52840, or it´s easy too like the NRF52832 ?

Posted at 2019-06-09 by AkosLukacs

One more thing might be interesting is that the nRF52840 has a low speed mode with better sensitivity: -103dBm sensitivity at 125kbps BLE vs -96dBm of the nRF52832 at 1Mbps. Also +8dBm max output vs +4dBm of the nRF52832.
That 7dBm receive sensitivity increase theoretically should double the range.

Has anyone tested, or has data on potential range improvement (preferably inside a building)? Nordic has published pretty impressive range outdoors...

Is there any gotcha? Other than there is no support for Bluetooth 5 on either my phone or laptop & I have no idea about the intricacies of Bluetooth versions....

Posted at 2019-06-09 by tcpipchip

We got 1km range communication outdoor with NINA B3

Posted at 2019-06-09 by AkosLukacs

Oh, that's impressive. NINA B3 on both sides? What antenna did you use?

Posted at 2019-06-09 by tcpipchip

embedded antena!
nina to nina

Posted at 2019-09-11 by zeromem

Hi, any news about Nordic nRF52840 Dongle support? I just got one. Thank you.

Posted at 2019-09-11 by tcpipchip

I see that they are tryng to port it! I guy have success!

Did you see that ?

Posted at 2019-09-11 by @gfwilliams

I believe it's actually pretty reasonable when ported to the DK now, so if the dongle uses the same pinouts then you could use the exact same hex file from that.

Unfortunately Nordic are only supporting the Thingy at the moment. Maybe if enough people prodded them they could be convinced to get me to do builds for the dongle ;)

Posted at 2019-09-11 by tcpipchip

Yes, i agree with you!

But did you ported to dongle ?

Posted at 2019-09-12 by @gfwilliams

Not specifically, but Nordic do tend to use the same pinouts so the DK version may 'just work'

Posted at 2019-09-12 by tcpipchip

btw, i am writing a book about Alexa amazon and i would like to include your Espruino in a chapter, but needs to be to ESP32...and with 2Mb flash
Did you implemented SSL certificates to access AWS IOT ?

Posted at 2019-09-12 by @gfwilliams

Did you implemented SSL certificates to access AWS IOT ?

I think so. On official Espruino WiFi boards you can supply SSL certificates: http://www.espruino.com/Storing+HTTPS+Certificates

On ESP32? Not sure, but it's possible. As with all this stuff while it'd be nice to support more hardware, I have to run a business and more hardware means more dev and support work for me - and yet no more income.

Posted at 2019-09-12 by user95229

Gordon

Very interesting! Before i tests ESP32 + SSL + ASW IOT, please, tell me if ESPRUINO will runs in a 2Mb FLASH ESP32? I will use NINA W102.
if you say, dont loose time! It does not work! I cancel

Posted at 2019-09-12 by tcpipchip

I am testing first on WROOM! Works fine using TERATERM...
But ESPRUINO IDE not estabilish communication. Some tip ?

Posted at 2019-09-13 by tcpipchip

found! 115200

Posted at 2019-09-14 by tcpipchip

Gordon,
tryng to add ESPRUINO ESP32 to book, but...

Saving key
Saving cert
Connecting to Wifi
Saving ca
Done!
Connected...
Acessing AWS IOT
Connecting...
Uncaught InternalError: HTTPS init failed! mbedtls_x509_crt_parse of 'ca': Invalid format
at line 73 col 10
}).end();
^
in function called from system
Acessing AWS IOT
Connecting...
Uncaught InternalError: HTTPS init failed! mbedtls_x509_crt_parse of 'ca': Invalid format
at line 73 col 10
}).end();
^
in function called from system

Very strange :(

Posted at 2019-09-14 by tcpipchip

https://www.dropbox.com/s/dj6fcj0039064bj/gordon.png?dl=0

Posted at 2019-09-16 by AkosLukacs

Tried to build for the nRF52840 DK, but ran into two issues with provisioning:

First at line 160 in provision.sh: mv nRF5_SDK_15.0.0_a53641a/* targetlibs/nrf5x_15, the output contains some errors:

mv: cannot move 'nRF5_SDK_15.0.0_a53641a/components' to 'targetlibs/nrf5x_15/components': Permission denied
mv: cannot move 'nRF5_SDK_15.0.0_a53641a/config' to 'targetlibs/nrf5x_15/config': Permission denied
mv: cannot move 'nRF5_SDK_15.0.0_a53641a/documentation' to 'targetlibs/nrf5x_15/documentation': Permission denied
mv: cannot move 'nRF5_SDK_15.0.0_a53641a/examples' to 'targetlibs/nrf5x_15/examples': Permission denied
mv: cannot move 'nRF5_SDK_15.0.0_a53641a/external' to 'targetlibs/nrf5x_15/external': Directory not empty
mv: cannot move 'nRF5_SDK_15.0.0_a53641a/external_tools' to 'targetlibs/nrf5x_15/external_tools': Permission denied
mv: cannot move 'nRF5_SDK_15.0.0_a53641a/integration' to 'targetlibs/nrf5x_15/integration': Permission denied
mv: cannot move 'nRF5_SDK_15.0.0_a53641a/modules' to 'targetlibs/nrf5x_15/modules': Permission denied

Second is the SDK15 NFC patches. Which file should be patched?
Provision.sh:

  echo ======================================================
 echo "FIXME - SDK15 NFC patches don't apply cleanly"
 echo ======================================================
 cat targetlibs/nrf5x_15/patches/* | patch -p1

Output:

 ======================================================
 FIXME - SDK15 NFC patches don't apply cleanly
 ======================================================
can't find file to patch at input line 17
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|From 97718ae8b320e9be84e533bb60c617d4c440d688 Mon Sep 17 00:00:00 2001
|From: AntiCat <github@anticat.ch>
|Date: Fri, 26 May 2017 02:48:29 +0200
|Subject: [PATCH 1/7] NFC: Removed NDEF frontend, prepared raw backend.
|
|Implementing NDEF in JS requires access to 10 byte
|tag header, holding UID and BCC.
|---
| .../nrf5x/components/nfc/t2t_lib/hal_t2t/hal_nfc_t2t.c   | 16 +++++++++++++---
| .../nrf5x/components/nfc/t2t_lib/hal_t2t/hal_nfc_t2t.h   |  1 +
| 2 files changed, 14 insertions(+), 3 deletions(-)
|
|diff --git a/targetlibs/nrf5x_15/components/nfc/t2t_lib/hal_t2t/hal_nfc_t2t.c b/targetlibs/nrf5x_15/components/nfc/t2t_lib/hal_t2t/hal_nfc_t2t.c
|index 1235e1d6..ca8b5cbf 100644
|--- a/targetlibs/nrf5x_15/components/nfc/t2t_lib/hal_t2t/hal_nfc_t2t.c
|+++ b/targetlibs/nrf5x_15/components/nfc/t2t_lib/hal_t2t/hal_nfc_t2t.c
--------------------------
File to patch:

Posted at 2019-09-17 by @gfwilliams

Not sure what's up with the permission issues at all. I don't get that, and it should be an empty directory I'd have thought :/

Also with NFC, it just doesn't work at the moment on SDK15. Just ignore the patch errors and it should still work as long as you don't try and enable NFC functionality.

Posted at 2019-09-17 by AkosLukacs

Thanks, looks like the permission issues are some kind of WSL & remote VSCode locking up freakshow. Manually copying and moving solved the problem.

Edit: Applied the last patch 0008-GPIO-Fix-broken-includes.patch, and built it successfully!

Posted at 2019-09-17 by AkosLukacs

Update: the 52840-DK does work: Can connect via virtual serial thru the built-in JLink + native USB(serial) + BLE. \o/

But couldn't get it working on the dongle :(

First try: just flash the same hex with nRF Connect. No luck.
The green LED was blinking periodically, took a look at the schematics: Of course the serial pins used on the DK are not really available on the dongle. The DK's tx pin is P0.06 - the green LED on the dongle. So took a look at the LED with a logic analyzer, and indeed it's crying into the void at 9600 bps: NRF ERROR 0x3 at ?:0 REBOOTING.

Tried to create a board file for the dongle, but no luck. Compiles OK, but doesn't do anything :/ Attached the board file, if anyone wants to give it a try.

Attachments:

NRF52840DO.py

Posted at 2019-09-17 by AkosLukacs

Got it working \o/
I think the pins need some cleanup (a couple of pins are not available on the dongle)
Attached the board and hex files, if anybody want to play around.

Attachments:

Posted at 2019-09-18 by zeromem

Working on my dongle! Thank you!

>process.env
={
  VERSION: "2v04.33",
  GIT_COMMIT: "f34cce8e",
  BOARD: "NRF52840DONGLE",
  FLASH: 1048576, RAM: 262144,
  SERIAL: "321d5edb-78df5aa8",
  CONSOLE: "Bluetooth",
  MODULES: "Flash,Storage,hea" ... "etworkJS,neopixel",
  EXPTR: 536885656 }
>

Posted at 2019-09-19 by @gfwilliams

That's great! Thanks! You ok with me pulling that into the UNMAINTAINED_BOARDS branch?

Posted at 2019-09-19 by AkosLukacs

There are still some small issues:
Can I remove pins? Some pins are not routed to pads, and some pins are connected together to make routing easier (from the dongle manual):

SW2 is also connected to P0.19, P0.21, P0.23, and P0.25. This is done to simplify PCB routing. These GPIOs should not be used and should be left as input with no pull or be disconnected by firmware.

So those pins should not be toggled even accidentally. Toggling a pin that's not routed is no issue, but if someone sets these pins to different output values, that could fry the board I guess. Tiny chance, but still...

The green LED (D6 IIRC) is turned on after boot. I can toggle it later, but strange. Any idea why?

The LEDs are active low, so they turn off on the first toggle. Something like

 # Make buttons and LEDs negated
  pinutils.findpin(pins, "PD13", True)["functions"]["NEGATED"]=0;

should solve it?

Posted at 2019-09-23 by @gfwilliams

I answered the pin removal thing in your other post - so it should be easy enough to remove them.

And yes, doing the negation should fix the LED thing I'd have thought.

Posted at 2019-09-30 by tcpipchip

Running now on UBLOX NINA B302 too!
Congratulations to all!

Attachments:

Sem título.png

Posted at 2019-09-30 by tcpipchip

How can i do make direct access to GPIO P0.30 ?
I want to make it to blink a led in my ESPRUINO BLOG with NINA B302

Posted at 2019-09-30 by AkosLukacs

D30.toggle() should do the trick

Posted at 2019-09-30 by user95229

D30 maps to direct io P030 ?
Nice! I will do that this night

Posted at 2019-10-01 by tcpipchip

hI, d30 IS not mapped to P030.

Who is mapped to P030 is D2

Wich files has this map to me to follow ?

Posted at 2019-10-01 by AkosLukacs

Should be. Haven't tested all, just the LEDs and button available on the 52840 dongle, and those were working:

  'BTN1' : { 'pin' : 'D38' }, # the button is at P1.06
  'LED1' : { 'pin' : 'D6' },  # green LED
  'LED2' : { 'pin' : 'D8' },   # RGB LED / red   P0.08
  'LED3' : { 'pin' : 'D41' },  # RGB LED / green P1.09
  'LED4' : { 'pin' : 'D12' },  # RGB LED / blue  P0.12

All pins should be there. P0.00 as D0 and so on. P1.00 is D32 and so on.
The pins are just defined by the board.py I uploaded in the previous post: http://forum.espruino.com/comments/14905935/ the line pins = pinutils.generate_pins(0,47) # 48 General Purpose I/O Pins.

Posted at 2019-10-02 by tcpipchip

Akos, if i send my personal MAP, can you compile to me ?

Or, if you give instructions to compile i can do here...i had done 832 year ago!

Thanks!

Posted at 2019-10-02 by AkosLukacs

Just follow the build instructions :)
Provisioning was kind of messy on windows with WSL, but otherwise it's not really difficult.
Or send me the board file, if you can't get it working.

Posted at 2019-10-02 by tcpipchip

:)

The main is change

devices = {
'BTN1' : { 'pin' : 'D38' }, # the button is at P1.06
'LED1' : { 'pin' : 'D6' }, # green LED
'LED2' : { 'pin' : 'D8' }, # RGB LED / red P0.08
'LED3' : { 'pin' : 'D41' }, # RGB LED / green P1.09
'LED4' : { 'pin' : 'D12' }, # RGB LED / blue P0.12
'RX_PIN_NUMBER' : { 'pin' : 'D13'},
'TX_PIN_NUMBER' : { 'pin' : 'D15'},
};

Right ?

I will want to map
GPIO_1 to GPIO_52 names to the NINA B302

For example,
GPIO_1 will be the physical pin P0.13
GPIO_2 will be the physical pin P0.14
and soon
How can i define one of those..
What is D38, D6, etc ?
For example, is D0 mapped as P0.0, D1 mapped as P0.1 ?

Attachments:

Sem título.png

Posted at 2019-10-02 by AkosLukacs

I have a new build, fixes:

Button and the 4 LEDs are negated
Only accessible pins are available from Espruino (for example there is no D3, because P0.03 is not routed on the dongle)

Board file two hex files are attached: 2v04.105 is built from the same commit as the previous one, 2v04.121 is from the latest master. Bluetooth and USB serial works, haven't done much testing...

@tcpipchip Don't exactly remember what made it working, IIRC make everything "right"...
Right now P0.00 is D0, P0.01 is D1 ... P0.31 is D31. P1.00 is D32, P1.01 is D33 and so on.

You can do that from JS (or wrap it in an object, if you'd like to):

GPIO_1 = D13
GPIO_2 = D14

Or - since the dongle build file defines the LEDs, button, and two pins for serial, you might want to create your own board file, and the pin naming could be done like the NodeMCU pin aliases: Add an extra file that defines aliases: Something like Nina.GPIO_1 is an alias for D13.

@gfwilliams I have one last (hahaha) question: The nRF52840 has pins on P0 and P1. right now P1.00 maps to D32, that's kind of annoying (thoughts in my brain: do I add 31 or 32 or wat?). Tried to mess with the board file and build_pininfo.py, and I could make a mess and create for example an E9 pin, but didn't work.
Can we map P1.00 to (for example) E0, P1.01 to E1, and so on?
The button and an LED is on P1 right now, and those do work, just don't like the pin names this way :)

Attachments:

Posted at 2019-10-02 by zeromem

Working on my dongle! Thank you!

>process.env
={
  VERSION: "2v04.121",
  GIT_COMMIT: "572d768e",
  BOARD: "NRF52840DONGLE",
  FLASH: 1048576, RAM: 262144,
  SERIAL: "321d5edb-78df5aa8",
  CONSOLE: "Bluetooth",
  MODULES: "Flash,Storage,hea" ... "etworkJS,neopixel",
  EXPTR: 536885656 }
>

Posted at 2019-10-02 by tcpipchip

Ready, can you compile ?

#!/bin/false
# This file is part of Espruino, a JavaScript interpreter for Microcontrollers
#
# Copyright (C) 2013 Gordon Williams <gw@pur3.co.uk>
#
# This Source Code Form is subject to the terms of the Mozilla Public
# License, v. 2.0. If a copy of the MPL was not distributed with this
# file, You can obtain one at http://mozilla.org/MPL/2.0/.
#
# ----------------------------------------------------------------------------------------
# This file contains information for a specific board - the available pins, and where LEDs,
# Buttons, and other in-built peripherals are. It is used to build documentation as well
# as various source and header files for Espruino.
# ----------------------------------------------------------------------------------------

import pinutils;

info = {
 'name' : "nRF52840 U-BLOX NINA B302",
 'link' :  [ "https://www.nordicsemi.com/Software-and-Tools/Development-Kits/nRF52840-Dongle" ],
 'espruino_page_link' : 'nRF52840_B302',
  # This is the PCA10059
 'default_console' : "EV_SERIAL1",
 'default_console_tx' : "D45",
 'default_console_rx' : "D29",
 'default_console_baudrate' : "9600",
 'variables' : 12500, # How many variables are allocated for Espruino to use. RAM will be overflowed if this number is too high and code won't compile.
# 'bootloader' : 1,
 'binary_name' : 'espruino_%v_nrf52840_dongle.hex',
 'build' : {
   'optimizeflags' : '-Os',
   'libraries' : [
     'BLUETOOTH',
     'NET',
     'GRAPHICS',
     'NFC',
     'NEOPIXEL'
   ],
   'makefile' : [
     'DEFINES += -DCONFIG_GPIO_AS_PINRESET', # Allow the reset pin to work
     'DEFINES += -DBOARD_PCA10059',
     'DEFINES += -DNRF_USB=1 -DUSB',
     'NRF_SDK15=1'
   ]
 }
};


chip = {
  'part' : "NRF52840",
  'family' : "NRF52",
  'package' : "QFN48",
  'ram' : 256,
  'flash' : 1024,
  'speed' : 64,
  'usart' : 2,
  'spi' : 3,
  'i2c' : 2,
  'adc' : 1,
  'dac' : 0,
  'saved_code' : {
    'address' : ((246 - 10) * 4096), # Bootloader takes pages 248-255, FS takes 246-247
    'page_size' : 4096,
    'pages' : 10,
    'flash_available' : 1024 - ((31 + 8 + 2 + 10)*4) # Softdevice uses 31 pages of flash, bootloader 8, FS 2, code 10. Each page is 4 kb.
  },
};

devices = {
  'GPIO_1' 	: 			{ 'pin' : 'D13' }, 
  'GPIO_2' 	: 			{ 'pin' : 'D14' }, 
  'GPIO_3' 	: 			{ 'pin' : 'D15' }, 
  'GPIO_4' 	: 			{ 'pin' : 'D16' }, 
  'GPIO_5' 	: 			{ 'pin' : 'D24' }, 
  'GPIO_7' 	:		 	{ 'pin' : 'D25' },
  'GPIO_8' 	: 			{ 'pin' : 'D32' },
  'GPIO_16' : 			{ 'pin' : 'D3'  }, 
  'GPIO_17' : 			{ 'pin' : 'D28' }, 
  'GPIO_18' : 			{ 'pin' : 'D2'  }, 
  'GPIO_20' : 			{ 'pin' : 'D31' }, 
  'GPIO_21' : 			{ 'pin' : 'D44' }, 
  'GPIO_22' : 			{ 'pin' : 'D45' }, 
  'GPIO_23' :		 	{ 'pin' : 'D29' },
  'GPIO_24' : 			{ 'pin' : 'D30' },
  'GPIO_25' : 			{ 'pin' : 'D4'  },  
  'GPIO_27' : 			{ 'pin' : 'D5'  },  
  'GPIO_28' : 			{ 'pin' : 'D9'  },  
  'GPIO_29' : 			{ 'pin' : 'D10' },  
  'GPIO_32' : 			{ 'pin' : 'D11' },  
  'GPIO_33' : 			{ 'pin' : 'D41' },  
  'GPIO_34' : 			{ 'pin' : 'D40' }, 
  'GPIO_35' :		 	{ 'pin' : 'D33' },
  'GPIO_36' : 			{ 'pin' : 'D34' },
  'GPIO_37' : 			{ 'pin' : 'D35' },  
  'GPIO_38' : 			{ 'pin' : 'D42' },  
  'GPIO_39' : 			{ 'pin' : 'D43' },  
  'GPIO_40' : 			{ 'pin' : 'D47' },  
  'GPIO_41' : 			{ 'pin' : 'D46' },  
  'GPIO_42' : 			{ 'pin' : 'D26' },  
  'GPIO_43' : 			{ 'pin' : 'D6'  },  
  'GPIO_44' : 			{ 'pin' : 'D27' },  
  'GPIO_45' : 			{ 'pin' : 'D7'  },  
  'GPIO_46' : 			{ 'pin' : 'D12' },  
  'GPIO_47' : 			{ 'pin' : 'D23' },  
  'GPIO_48' : 			{ 'pin' : 'D21' },  
  'GPIO_49' : 			{ 'pin' : 'D22' },  
  'GPIO_50' : 			{ 'pin' : 'D20' },  
  'GPIO_51' : 			{ 'pin' : 'D17' },  
  'GPIO_52' : 			{ 'pin' : 'D19' }
};

# left-right, or top-bottom order
board = {
  'left' : [ 'VDD', 'VDD', 'RESET', 'VDD','5V','GND','GND','','','D3','D4','D28','D29','D30','D31'],
  'right' : [
     'D27', 'D26', 'D2', 'GND', 'D25','D24','D23', 'D22','D20','D19','',
     'D18','D17','D16','D15','D14','D13','D12','D11','',
     'D10','D9','D8','D7','D6','D5','D21','D1','D0'],
  '_notes' : {
    'D13' : "Serial console RX",
    'D15' : "Serial console TX"
  }
};
board["_css"] = """
#board {
  width: 528px;
  height: 800px;
  top: 0px;
  left : 200px;
  background-image: url(img/NRF528DK.jpg);
}
#boardcontainer {
  height: 900px;
}

#left {
    top: 219px;
    right: 466px;
}
#right {
    top: 150px;
    left: 466px;
}

.leftpin { height: 17px; }
.rightpin { height: 17px; }
""";

def get_pins():
  pins = pinutils.generate_pins(0,47) # 48 General Purpose I/O Pins.
  pinutils.findpin(pins, "PD0", True)["functions"]["XL1"]=0;
  pinutils.findpin(pins, "PD1", True)["functions"]["XL2"]=0;
  # pinutils.findpin(pins, "PD5", True)["functions"]["RTS"]=0;
  # pinutils.findpin(pins, "PD6", True)["functions"]["TXD"]=0;
  # pinutils.findpin(pins, "PD7", True)["functions"]["CTS"]=0;
  # pinutils.findpin(pins, "PD8", True)["functions"]["RXD"]=0;
  # pinutils.findpin(pins, "PD9", True)["functions"]["NFC1"]=0;
  # pinutils.findpin(pins, "PD10", True)["functions"]["NFC2"]=0;
  pinutils.findpin(pins, "PD2", True)["functions"]["ADC1_IN0"]=0;
  pinutils.findpin(pins, "PD3", True)["functions"]["ADC1_IN1"]=0;
  pinutils.findpin(pins, "PD4", True)["functions"]["ADC1_IN2"]=0;
  pinutils.findpin(pins, "PD5", True)["functions"]["ADC1_IN3"]=0;
  pinutils.findpin(pins, "PD28", True)["functions"]["ADC1_IN4"]=0;
  pinutils.findpin(pins, "PD29", True)["functions"]["ADC1_IN5"]=0;
  pinutils.findpin(pins, "PD30", True)["functions"]["ADC1_IN6"]=0;
  pinutils.findpin(pins, "PD31", True)["functions"]["ADC1_IN7"]=0;
  # Make buttons and LEDs negated
  pinutils.findpin(pins, "PD13", True)["functions"]["RXD"]=0;
  pinutils.findpin(pins, "PD14", True)["functions"]["NEGATED"]=0;
  pinutils.findpin(pins, "PD15", True)["functions"]["TXD"]=0;
  pinutils.findpin(pins, "PD16", True)["functions"]["NEGATED"]=0;
  pinutils.findpin(pins, "PD11", True)["functions"]["NEGATED"]=0;
  pinutils.findpin(pins, "PD12", True)["functions"]["NEGATED"]=0;
  pinutils.findpin(pins, "PD24", True)["functions"]["NEGATED"]=0;
  pinutils.findpin(pins, "PD25", True)["functions"]["NEGATED"]=0;
  # TODO: SW2 is also connected to P0.19, P0.21, P0.23, and P0.25. This is done to simplify PCB routing. These
  #       GPIOs should not be used and should be left as input with no pull or be disconnected by firmware.

  # everything is non-5v tolerant
  for pin in pins:
    pin["functions"]["3.3"]=0;
  #The boot/reset button will function as a reset button in normal operation. Pin reset on PD21 needs to be enabled on the nRF52832 device for this to work.
  return pins

Posted at 2019-10-02 by Robin

Wed 2019.10.02

As @AkosLukacs suggested in #86, 'Just follow the build instructions' as two builds have been provided in #88

The following is a good starting point, see the AkosLukacs entry which is #8 in the entire thread, when expanded. The step-by-step instructions are what I am following to perform the exact task you wish to accomplish:

http://forum.espruino.com/comments/14873740/

Posted at 2019-10-03 by AkosLukacs

Without NFC, because I didn't apply the NFC patches, and build fails with NFC.
You had one typo int your board file at the penultimate line: Should start with # sign to make that line a comment.
And totally untested, compiled on the train :)

But yeah, @robin is right, try to get it building on your computer, so you can tweak the board file.

Attachments:

Posted at 2019-10-03 by @gfwilliams

Ok, I think you're after two things that are incompatible (I could be wrong though :).

Basically when you access a pin in Espruino, Espruino gets the hardware pin number and port from gen/jspininfo.c.

Normally, without PIN_NAMES_DIRECT, you can have a bunch of different name/number pins that access the same port. So E0 could map to pin number 32, eg. E0 -> P1.0.

But since you want to skip pins out as well, you use PIN_NAMES_DIRECT, which uses the pin number supplied in the pinInfo file, so a pin number 32 must always stay 32.

The other thing you could do is mess around with jshardware.c to make it look at the port bit of pinInfo, but I think that's pretty nasty and would require a bunch of changes.

Posted at 2019-10-04 by tcpipchip

Lucas
I compiled with parameters but i getting a 800K hex file! Strange!
Can you compile there ?

Posted at 2019-10-04 by AkosLukacs

The ~800k file is the ".app_hex", but there should be a bigger ".hex" file too.

Posted at 2019-10-04 by tcpipchip

then really something is wrong during my compile...

Posted at 2019-10-04 by AkosLukacs

@gfwilliams Saving code to the dongle doesn't work , but works on the nRF52840DK.
Tested save() and "Write To Flash" (from the IDE), neither works on nRF52840 dongle, but both work on the DK. Tried two builds on both: 2v04.33 and 2v04.121 (current latest), same behaviour.
I know neither is an official board, but any idea?

The DK:

>setInterval('LED2.toggle()', 333);
=1
>save()
=undefined
Compacting Flash...
Calculating Size...
Writing..
Compressed 200000 bytes to 6277
// And works just fine

The dongle:

>setInterval('LED2.toggle()', 333);
=1
>save()
=undefined
Compacting Flash...
Calculating Size...
// hangs there, and disconnects after a couple of seconds.
// nothing saved to flash, works just fine after power cycling...

Edit: thanks for the previous reply, of course I want to do something totally not supported with the pins :)

Posted at 2019-10-04 by @gfwilliams

Is it actually the same chip, or is it one with less flash memory?

You could try require("Storage").eraseAll() and see if it helps?

Posted at 2019-10-04 by AkosLukacs

nevermind, fix is in my next post :)

Posted at 2019-10-04 by zeromem

Same thing on my dongle. :(

>save()
=undefined
Compacting Flash...
Calculating Size...
Disconnected

>process.memory()
={ free: 12476, usage: 24, total: 12500, history: 7,
  gc: 0, gctime: 20.05004882812, "stackEndAddress": 537092912, flash_start: 0, "flash_binary_end": 478792,
  "flash_code_start": 966656, flash_length: 1048576 }

>require("Storage").getFree()
=40960
>

Posted at 2019-10-04 by AkosLukacs

Figured it out: The dongle ships with a USB bootloader, located at the end of the flash. And the saved code area is defined right there. Details here

Moved the saved code area a bit, and now everything seem to be working :)
Board file and hex attached.

(If I got the numbers right, but it's getting a bit late. Only tested with a small blinky code. Still, the 52840 has a ton of free flash, so moving the saved flash area is not a big deal)

Attachments:

Posted at 2019-10-05 by zeromem

Tested OK save().

>save()
=undefined
Compacting Flash...
Calculating Size...
Writing..
Compressed 200000 bytes to 6294

>process.env
={
  VERSION: "2v04.121",
  GIT_COMMIT: "572d768e",
  BOARD: "NRF52840DONGLE",
  FLASH: 1048576, RAM: 262144,
  SERIAL: "321d5edb-78df5aa8",
  CONSOLE: "Bluetooth",
  MODULES: "Flash,Storage,hea" ... "etworkJS,neopixel",
  EXPTR: 536885656 }
>

Posted at 2019-10-13 by AkosLukacs

Small update: I think solved the pin naming issue.
Created alternate pin names like it's done with the NodeMCU pins. For example you P1.09 can be accessed as P1.p09. I think better than doing all the math to add 9 and 32 :)

Or does anyone have a better idea for pin naming? P1.09 sort-of worked, but the autocomplete reported all kinds of weird ascii characters as properties. Espruino doesn't like properties starting with numbers, so decided to go with p as 'pin' prefix...

@tcpipchip did you solve your pin naming problem?

Attachments:

espruino_2v04.160_nrf52840_dongle__.hex

Posted at 2019-10-13 by user95229

I had aborted because was creating only a 800k size! I will test your version with new gpio map that you created! I will use on nina b302 :)

Posted at 2019-10-13 by zeromem

I tested the new version, thank you.

>process.env
={
  VERSION: "2v04.160",
  GIT_COMMIT: "e4a306e3",
  BOARD: "NRF52840DONGLE",
  FLASH: 1048576, RAM: 262144,
  SERIAL: "321d5edb-78df5aa8",
  CONSOLE: "Bluetooth",
  MODULES: "Flash,Storage,hea" ... "etworkJS,neopixel",
  EXPTR: 536885596 }
>

Posted at 2019-10-14 by tcpipchip

@AkosLukacs

Can you map all pins ?

For example, you forgot
P0.p03

D0...D31...D32...it´s working!

Posted at 2019-10-14 by AkosLukacs

Only mapped the pins available on the Nordic Dongle. For example P0.03 is not accessible on it. Attached the spreadsheet I used to create the pin maps.

But yes, I can map the rest of the pins, wanted to do that for the DK as that as all pins routed.

Attachments:

nrf52840_dongle_pins.ods

Posted at 2019-10-14 by tcpipchip

Nince @AkosLukacs

Please, map them :)

Thanks for all your help :)

Posted at 2019-10-14 by tcpipchip

wich are the default USART gpio txd / rxd used if i dont want USB serial ?

Posted at 2019-10-14 by AkosLukacs

RX: P0.13 (D13)
TX: P0.15 (D15)

Posted at 2019-10-14 by tcpipchip

Did you enable BLE in on your compile ?
getting this error during my SCAN to BLE modules making advertising...

Attachments:

Sem título.png

Posted at 2019-10-14 by tcpipchip

The same error to

var devices;
NRF.findDevices(function(d) {
  devices = d;
  console.log(devices);
}, 1000);

Uncaught Error: BLE error 0x6
 at line 38 col 8
}, 1000);
       ^
[  ]
Uncaught Error: BLE error 0x8 (INVALID_STATE)
>

Posted at 2019-10-14 by AkosLukacs

BLE is enabled, I can connect to the dongle via BLE & NUS.
But the same command fails for me too. I can set up advertising, but can't send notifications.
This is using a newer SDK version than the nRF52832 chips, and looks like there are missing things. :(

Posted at 2019-10-14 by tcpipchip

yes, that is a problem :(

Maybe gordon can see that SCAN problem :(

Posted at 2019-10-17 by @gfwilliams

That's a strange one - pretty sure I had stuff like that working just fine on the nRF52840 build. The only thing I knew was broken was setting the Scan Response data.

I'm afraid I don't have time to look into that at the moment though

Posted at 2019-10-17 by user95229

no problem! Verify when have time! 30 days is enough ? :)

Posted at 2020-01-17 by user108516

Hello,

good work on this! I ordered an makerdiary nRF52840 MDK USB Dongle (but own it not yet). Do you think this might work too?

For a project I need the dongle to connect to a bluetooth device and act as an HID-USB-Device. Does the USBKeyboard-Module work? Do someone ever tested it?

Thank you for your reply.

Posted at 2020-01-17 by AkosLukacs

I have an MDK dongle, but so far I couldn't get either Espruino, or Nordic's official long-range demo to work.
The official demo by makerdiary does work, and tried logitacker on it, that worked too.
My latest theory is different bootloader, but haven't yet opened up to SWD erase the whole chip.

Posted at 2020-05-15 by k.zabloudil

Hello,

I tried to flash AkosLukacs's hex file from this page to my nrf52840 dongle using nrfutil:

nrfutil pkg generate --hw-version 52 --sd-req 0 --application espruino_2v04.160_nrf52840_dongle.hex --application-version-string "2.4.0" dfu.zip
nrfutil dfu usb-serial -pkg dfu.zip -p COM5 -b 115200

it says that the device was programmed succesfully, but I can't connect to it (I do not see any BT device nor any COM port I can connect. the only port I see is the one I used for programming showing nRF52 SDFU USB (COM5))

any hint what can be wrong ?

thank your any advice...

Posted at 2020-05-15 by AkosLukacs

I don't think you need to create a DFU package. I just used the nRF Connect application's programmer. AFAIK that just calls nrfjprog.
I think you should try nRF Connect's gui, or just flash the hex with nrfjprog.

Posted at 2020-05-15 by k.zabloudil

thank you, I was able to flash and connect using nrf connect!

Posted at 2020-06-25 by rocksetta

I am new to all this, however I have been hacking various nrf5200 boards for a while. Anyone here used the Particle Debugger for $20.00 USD from Adafruit. It is fairly amazing, drag and drop .bin and .hex boot loading.

Here is a long blog about what I was trying to do on PlatformIO

Since I am new to the forum can someone summarize their experience with the NRF52840 USB dongle or similar with espruino? I have 3 of them.

Posted at 2020-06-25 by AkosLukacs

You have to build the firmware yourself, but just built one two days ago, see the attached hex. The board file is above somewhere.
Just plug it in a USB port, press the button to get into bootloader mode, and you can program it with Nordic's programmer.
And start hacking. USB and BLE both work.

Attachments:

espruino_2v06.6_nrf52840_dongle.hex

Posted at 2020-06-25 by rocksetta

Any extra tricks. I can install your hex file. But my windows 10 computer does not seem to see the port unless I put it in bootloader mode, but then flashing does not work.. Chrome extension seems to work fine. Doesn't help that I haven't even used espruino before so not sure if I am doing anything really silly.

Posted at 2020-06-25 by rocksetta

@k.zabloudil

I am at the same step. Flashing bootloader seems fine. I think windows probably needs a driver. Will look a bit more.

Just occurred to me that the problem is probably that I have never ran an official Espruino device. The driver that would normally install on first run is probably not installing. Will try that.

0 replies

espruino-discuss · 2025-02-12T16:55:16Z

espruino-discuss
Feb 12, 2025
Maintainer Author

Posted at 2020-06-26 by AkosLukacs

Ok, what do you mean by "flashing does not work" ? If flashing won't work, nothing will work :)
After flashing Espruino, the dongle shows up as a virtual COM port, nothing special, Windows says the driver is by Microsoft, so you shouldn't need any special driver I think. Or BLE, no driver needed at all.

So, I'm lazy to type so just use nRF Connect desktop's "Programmer". You can use the command line tools, the GUI is calling that, so the result should be the same...

The hex's SHA1 should be: 57B9580CE13F18498255EFE8BEDF3370FF040ADB. Re-download if it's different! There is a tiny chance of wrong download...
This will work if your dongle still has the original USB bootloader. If you have completely erased, or uploaded a different bootloader that doesn't work with nrfjprog, you will need an SWD programmer. But the end result should be the same.
Plug-in the dongle, and press the reset button (the one sideways). The red LED should start pulsing.
Launch nRF Connect & programmer. Select the device (top-left). The contents of the dongle's memory should be visible on the left. See the screenshot
Press "Clear files" if you have previously added any file. "Add HEX file" (top-right), select the dongle's hex and hit write. Should take half a minute or so.
Unplug & re-plug the dongle!
Now you should be able to connect to the dongle via BLE or USB. USB feels a bit not-so-perfect: I have to send an extra character sometimes to get the full response from the dongle. Didn't have this issue with BLE tho...

The programmer's log output should look like this:

2020-06-26T06:41:00.428Z INFO Using USB SDFU protocol to communicate with target
2020-06-26T06:41:00.446Z INFO Protocol Version:  1 found
2020-06-26T06:41:00.447Z INFO Hardware: 52840 found
2020-06-26T06:41:00.452Z INFO Firmware: Bootloader found
2020-06-26T06:41:00.452Z INFO Firmware: SoftDevice found
2020-06-26T06:41:00.453Z INFO Firmware: Application found
2020-06-26T06:41:17.200Z INFO Parsing HEX file:  C:\dev\espruino\_firmware\nRF52840\espruino_2v06.6_nrf52840_dongle.hex
2020-06-26T06:41:17.201Z INFO File was last modified at  23/06/2020, 18:24:22
2020-06-26T06:41:17.475Z INFO SoftDevice detected, id 0xA9 (S140 v6.0.0)
2020-06-26T06:42:36.283Z INFO Does not need to be reloaded:  C:\dev\espruino\_firmware\nRF52840\espruino_2v06.6_nrf52840_dongle.hex
2020-06-26T06:42:36.294Z INFO SdReq for SoftDevice is set as 0x00.
2020-06-26T06:42:36.296Z INFO Hash is generated by SHA256
2020-06-26T06:42:36.298Z INFO Hash is generated by SHA256
2020-06-26T06:42:36.311Z INFO Performing DFU. This may take a few seconds
2020-06-26T06:42:36.380Z INFO DFU procedure starts. This may take a few seconds.
2020-06-26T06:42:44.785Z INFO DFU for SoftDevice completed successfully!
2020-06-26T06:42:44.786Z INFO 1 dfu package(s) left.
2020-06-26T06:42:44.787Z INFO Waiting for device
2020-06-26T06:42:44.899Z INFO DFU procedure starts. This may take a few seconds.
2020-06-26T06:42:59.791Z INFO DFU for Application completed successfully!
2020-06-26T06:42:59.791Z INFO 0 dfu package(s) left.
2020-06-26T06:42:59.792Z INFO Waiting for device
2020-06-26T06:43:04.793Z ERROR Reopen device failed: Timeout while waiting for device  C132E264CC6B to be attached and enumerated
2020-06-26T06:43:04.793Z INFO Nordic DFU Trigger Interface was not found.Please physically reset device.
2020-06-26T06:43:04.796Z ERROR Device not found due to failure during DFU
2020-06-26T06:43:04.810Z INFO Target device closed.

Small correction, looks like I lost my latest board file, so BTNs and LEDs are the same as on the devkit, and that's not correct. But for example D6.toggle() does toggle the green LED. Just look up the pin numbers in the dongle's user guide.

Attachments:

Posted at 2020-06-26 by @fanoush

As for bootloader, the one in espruino tree worked for me with Particle Xenon so it is also possible to build the board file with bootloader turned on and then flash it including espruino bootloader and use DFU over ble. I think with generating DFU package it just needed some change to use NRF52840 family for nrfutil when making the zip or bootloader would otherwise not accept it. But SWD is faster anyway (or usb).

As for usb console prompt, yes it works somehow but I better disconnect USB as it interferes with ble console and it does something strange for me with Xenon at boot/reset time. Not using Xenon with Espruino very much but so far it mostly worked just fine for testing 52840 capabilities, no rough edges. And BTW with 256K of RAM one can hit Espruino limit that you can't allocate variable over 64KB size like e.g. new UInt8Array(240*240*2) for framebuffer (wasteful, I know, but 256KB!).

Posted at 2020-06-26 by @fanoush

Anyone here used the Particle Debugger for $20.00 USD from Adafruit. It is fairly amazing, drag and drop .bin and .hex boot loading.

It uses CMSIS-DAP, one of possible SWD implementations, feels better than stlink to me, e.g. can erase locked nrf52 chips, also works over USB HID so need no special usb drivers installed, also have UART included, I like it too. Don't have the one from Particle but there are also CMSIS-DAP implemenations for blue pill boards or STLINK V2 clones ($2 items). Interesting that the photo of Particle Debugger shows GD32F103 chip - clone of STM32F103.

Posted at 2020-06-28 by parasquid

@AkosLukacs just wanted to let you know that your intstructions (and sample .py file) were very helpful :)

>process.env
={
  VERSION: "2v06.10",
  GIT_COMMIT: "9811e3d",
  BOARD: "NRF52840DONGLE",
  FLASH: 1048576, STORAGE: 40960, RAM: 262144,
  SERIAL: "xxx",
  CONSOLE: "Bluetooth",
  MODULES: "Flash,Storage,hea" ... "etworkJS,neopixel",
  EXPTR: 536885592 }

Posted at 2020-12-23 by user95229

Hi
Have you news instructions to compile to NRF52840 ?

Posted at 2021-01-06 by tcpipchip

i had tried many times! No works! still uses the SDK 15 ?

Posted at 2021-01-07 by @fanoush

I see no difference building for nrf52840 dongle than building for any other board, yes SDK15 based build works on dongle.

after calling ./scripts/provision.sh YOURBOARDNAME with SDK15 based board name it sets up SDK15 and build should work.

BTW as for nrf52840 dongle, there is cheap 'clone' that often sells for $6.65 including shipping https://www.aliexpress.com/item/1005001530238972.html , got few of them and for the price it is good 52840 board. It is clone in the sense that button and LEDs pinout is same and same pins are brought out as on the original dongle. Otherwise it looks different and has also plastic case.

Also any nordic firmware and tools made for nrf52840 dongle works on this one too (connectivity fw, bt sniffer,...)

Posted at 2021-01-07 by user95229

Thanks for your good explanation!!!!
@fanoush
I forgot to use the
./scripts/provision.sh
I will test soon! And write blogs about espruino nina b302! I did a PCB to have access to all gpio
Thanks again! I will let you know the sucess

Posted at 2021-01-07 by tcpipchip

@fanoush
Thanks!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
u-blox nina B302 running GORDON JAVASCRIPT :)

Attachments:

Sem título.png

Posted at 2021-01-08 by tcpipchip

https://u-blox-nina-b112-javascript.blogspot.com/2021/01/compilando-espruino-para-u-blox-nina.html

Posted at 2021-01-15 by tcpipchip

https://windows7-ble-scan.blogspot.com/2021/01/criando-um-android-app-para-acesso-ao.html

NEW BLOG :)

Posted at 2022-03-25 by user141817

Is the scan issue fixed in a new hex? I am also seeing this error.
BTW, the link for espruino_2v06.6_nrf52840_dongle.hex does not seem to work anymore

Posted at 2023-12-20 by DanDyse

Just made a built for nrf52840 without USB/LED.

Attachments:

espruino_2v19.119_nrf52840.hex

0 replies

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Espruino JavaScript

Nordic "nRF52840 Dongle" Support #6870

{{title}}

Replies: 2 comments

{{title}}

{{title}}

Select a reply

Espruino JavaScript

Nordic "nRF52840 Dongle" Support #6870

espruino-discuss Feb 12, 2025 Maintainer

Replies: 2 comments

espruino-discuss Feb 12, 2025 Maintainer Author

espruino-discuss Feb 12, 2025 Maintainer Author

espruino-discuss
Feb 12, 2025
Maintainer

espruino-discuss
Feb 12, 2025
Maintainer Author

espruino-discuss
Feb 12, 2025
Maintainer Author