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/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](http://forum.espruino.com/search/?q=%23define) NRFX_UARTE_ENABLED 0
[#define](http://forum.espruino.com/search/?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:
when trying the bluetooth UART. If I switch to USB, then try to connect via bluetooth, I get this instead:
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:
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
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:
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:
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: 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.
So far, I learned that I can poke the GPIO register to make it work:
poke32(0x50000300+0x518, 1 << 11)
poke32(0x50000300+0x50c, 1 << 11)
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](http://forum.espruino.com/search/?q=%23if) defined (NRF52)
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 provision.sh 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
Don't worry about formatting, just type in the text and we'll take care of making sense of it. We will auto-convert links, and if you put asterisks around words we will make them bold.
For a full reference visit the Markdown syntax.
© Espruino, powered by microcosm.
Report a problem