-
• #27
@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](https://forum.espruino.com/search/?q=%23define) NRFX_UARTE_ENABLED 0 [#define](https://forum.espruino.com/search/?q=%23define) NRFX_UARTE0_ENABLED 0
-
• #28
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...
-
• #29
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.
-
• #30
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](https://forum.espruino.com/search/?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](https://forum.espruino.com/search/?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
-
• #31
Nice - thanks! That's a great spot. Do you want to add a PR for that change, or shall I pull it in?
-
• #32
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...)
-
• #33
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. -
• #34
Actually, just merged into Master
-
• #35
Alright, thanks, I'll have a go with a fresh download and see how it goes.
-
• #36
It's happy now that it's merged. 👍
-
• #38
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. -
• #40
Interesting - thanks! Looks like it needs a bit of refactoring done so that maybe
advertising_init
andjsble_advertising_start
use the same code -
• #41
@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
digitalWrite
ing 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? -
• #42
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 injshardware.c
: https://github.com/espruino/Espruino/blob/master/targets/nrf5x/jshardware.c#L652I guess there might be a different function to
nrf_gpio_pin_write
needed for GPIO1? If so, I'd add an 'if' based onpinInfo[pin].port
and ensure that the port gets set correctly in the BOARD.py file. -
• #43
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. - Set it to output -
-
• #44
I managed to narrow it down by looking at the generated assembly code - it seems like for some reason,
GPIO_COUNT
is set to1
, thus causing the wrong branch to be taken innrf_gpio_pin_port_decode()
innrf_gpio.h
. -
• #45
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](https://forum.espruino.com/search/?q=%23if) defined (NRF52) [#ifndef](https://forum.espruino.com/search/?q=%23ifndef) NRF52832_XXAA [#define](https://forum.espruino.com/search/?q=%23define) NRF52832_XXAA [#endif](https://forum.espruino.com/search/?q=%23endif) [#endif](https://forum.espruino.com/search/?q=%23endif)
This defines
NRF52832_XXAA
, and thus causing bothnrf52832_peripherals.h
andnrf52840_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?
-
• #46
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. -
• #47
Agreed - PR on its way, along with some other fixes that are required for making GPIO1 work
-
• #48
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?
-
• #50
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!
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.