Arduino on Nordic BLE nRF51822

Hi, first post on the forum

I tried couple of things on my cheap Chinese NRF51822 modules after I saw your post. I’m able to use these boards with mbed sdk and they are working great by the way.

RBL boards has another Freescale MCU on them to maintain SWD-USB interface and they are using custom bootloader instead of Nordic’s OTA bootloader. This makes things a little bit complicated. I wanted to try OTA first, so I loaded RedBear bootloader to the chip using jtag without a problem and connected a led on Pin13. Led is blinking fast and when I check Nordic toolbox app on iPhone, looks like it’s already in DFU mode. But I can’t connect to it. Nordic’s documents clearly tells which pin you should pull down to put the device in DFU mode, if you are using official OTA bootloader. Tried that, didn’t work. Here’s the complicated part. RBL says you should just press the reset button, and it will wait for connection for 5 seconds in DFU mode. But reset button is not connected to NRF, It’s connected to the Freescale MCU. So I think they have created their own Reset/DFU scenario in the bootloader. By the way blinking led looks like missing a step once in 4 seconds so I think its resets itself. That’s why I couldn’t connect to it, I guess.

Then I tried to load blink example to the application region on the NRF, using jtag, without touching RBL bootloader and BTstack. It didn’t work either, same result. Looks like it stuck in some sort of DFU-Reset loop. I tried a different power supply, nothing changed.

I’m kind of new to all these and I’m out of ideas. If you want me to try anything else, just let me know.

Hi Ozan

Sorry your posts were blocked.

Its an Anti spam thing in Off Topic, as most spam comes in that way .
Anyway, it should be OK now. PM me if its not. (PS I am Admin )

Anyway. Back to your question..

I think I made it work but I need to double check.

I flashed RBL’s bootloader onto the module using an STLink adaptor (I have for STM processors) and using OpenOCD

Once I’d flashed the bootloader, I scanned using an iPhone using an app called LightBlue and it found a DFU device advertising on BLE. I think as the rest of the flash was empty, the bootload just stayed in DFU mode.

There is probably an Adroid App that does the same thing, I just happen to have the iPhone app no an iPhone I use for BLE testing.

Anyway, I installed the nRFToolbox on an Android device, and followed the instructions from RBL about OTA uploading.
I had to connect my Android device to my PC to copy the Hex file generated by the IDE, and after it was uploaded by the phone to the module, the DFU went away, and I was able to see a UART device from the nRFToolbox – as I had compiled the UART example from RBL (installed when you install the RBL Arduino core)

So I thought perhaps I can upload direct using STLink (JTAG), rather than using this complicated DFU method.

So I looked in the linker file and I can see the offset for the code is. See line 5

https://github.com/RedBearLab/nRF51822- … RF51822.ld

MEMORY
{
FLASH (rx) : ORIGIN = 0x0001C000, LENGTH = 0x24000
RAM (rwx) : ORIGIN = 0x20002800, LENGTH = 0x1800
}

I just re-read the RBL readme on github

I’m not sure if the freescale chip uploads via SWD or whether this is something handled internally by the bootloader. I just using the freescale chip to convert the incoming serial to SWD it would make the bootloader smaller, but in which case, I’m not sure a bootloader would be needed at all.

However using a whole freescale chip just to determine whether the IDE wants to flash the device seems like overkill.
Looking at the bootloader, I think it has a nordic soft device at the start of the file.

As I can find many matches for this soft device in the hex

https://developer.mbed.org/users/mbed_o … device.hex

But they may be using a different soft device.

Anyway, at a rough guess the actual bootloader code is probably 15k of the 60k of the total bootloader (soft device looks like it is about 45k – but this is a educated guess)

I’d say 15k is enough to implement both the DFU and serial upload types, as the STM32 bootloader including the USB libs is around 8k, and only does DFU.

So…
Where does this leave us.

Well, if we need a device to mimic the freescale chip, a Black Magic Probe seems the best solution, as this can be flashed onto a $5 STM32 board and provides both SWD and also USB to serial

Just a bit more information, you may already know

I plugged in a USB to Serial adaptor and set that as the com port for uploads, compiled for upload.

Interesting thing is that they appear to use AVRDude as the programming tool

C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avrdude -CC:\Users\me\AppData\Roaming\Arduino15\packages\RedBearLab\hardware\nRF51822\1.0.0/avrdude_conf/avrdude.conf -v -v -v -v -pcortex-m0 -cavr109 -PCOM16 -b115200 -D -Uflash:w:C:\Users\me\AppData\Local\Temp\build5507143968402139026.tmp/sketch_oct30a.cpp.hex:i

So. I suspect that the freescale processor is behaving as if its the bootloader in an AVR Arduino to fool the normal AVRDude uploader into thinking its uploading to a normal AVR board.

I guess this saved RBL from having to write and compile upload tools for all platforms, as well as writing code for the bootloader and the freescale chip

Sorry for the late reply.
Finally I’m able to put apps using OTA. The problem was my Iphone i guess but iPad did the trick. You have 5 seconds to connect and press upload or it drops the connection. It goes OTA mode for 5 seconds, then app starts, whenever I reset it. If there is no app in it, DFU-Reset loop starts as you mentioned.

The problem is, if I load the app to the app region using jtag, it’s starting to make DFU-Reset loop thing again and i can’t get out of it. DFU still works and I can upload files. Which means, I’m not corrupting Softdevice or bootloader, I guess. At the RBL forum, they say it happens when you corrupt or erase Freescale chip.
Nordic says;
Note that if you program a DFU bootloader on the device, you must use this bootloader to install the application. Programming the application with other tools will not update the bootloader settings, which means that the application might not start. Erase the device if you do not want to use the DFU bootloader anymore.
I think this is the case and they overcome this situation by using Freescale chip somehow.

Now the good news. Since they have merged Softdevice and bootloader in one file. I loaded merged file to the chip and read back just the softdevice and load it back without bootloader. And loaded just the RBLController app to the app region. It worked!!! It gets better. There is Nordic’s example for OTA bootloader on s130. There is also a Serial DFU bootloader example. I will try to make it work and maybe merge serial bootloader with s130 softdevice.
From the Nordic’s SDK documentation;
The DFU Bootloader is capable of receiving an application image on the UART and updating the current running application on the nRF51822 chip. If no application image is present in the Code Region 1 of the nRF51822 flash area, the DFU Bootloader will listen on the UART for an application image.
That’s exactly what we want. Heres the softdevice file btw. It should work with official s130 but there are different versions. I didn’t want to risk it.

I’m using Nordic’s tools with Segger j-link BTW. nRFgo Studio(programmer) recognizes chip model and it’s region limits then compares with the file you want to load. There are 3 different NRF chips. If you are using AA variant like me, according to NRFgo Studio, your offset values seems OK for flash. I can’t see Ram values.

Hi Ozan.

Re:RBL bootloader

Yes. I just looked at the Hex file that i flashed to the module, and it looked like the first 40k was a soft device. I presumed that their bootloader could would need all the BLE functions, so its similar to statically linking a BLE lib with user code.

However I could not determine which soft device version they used.

I read some information on the Nordic website, and it said the Softdevice size and hence application offset changes depending on what soft device you use, so the linker setting most match the Softdevice.

In this case RBL use 0x0001C000 offset, so this may be a clue to which soft device they used.

But as you managed to extract the softdevice (only) from the bootloader data, We can use this until we know which softdevice they actually used.

Perhaps at some point we can use another softdevice if necessary, but would need to change the linker settings in the Arduino files.

Re:uploading using JTAG.

I have a JLink clone, but I dont like it. I think it does not output 3.3v.

So I am using my STLink adaptor, and it works fine with OpenOCD.

But perhaps I should solder a 3.3V regulator to my module, so I can try the Jlink with the Nordic software rather than using OpenOCD.

In the longer term however I think OpenOCD will be better, as @rickkimball, already wrote the commands to upload to STM32 using OpenOCD, directly from inside the IDE.

Anyway.

If I erase all the flash
Flash the softdevice you posted.
then flash a blink sketch hex file ( made by the Arduino IDE)

Should I be able to see a led flash If I attach one to pin P0.00 ?

Some more progress

I flashed the S130 hex you posted

Compiled a blink sketch flashing pin 4

I used my multimeter to look at the voltages on the pins and a pin with no name on it was flashing.

But I worked out its pin P0.21

Image
Ignore the stuff about RIOT, I just took the image from their wiki

So the RBL stuff has some bizarre pin mapping to suit their hardware.

Its in pin_transform.cpp

This is a pain, so I’m thinking of forking their repo and ripping out the pin transform stuff, so that the real pin names can be used

Anyway. At least GPIO is working, so I’d like to try to get Serial working next

However this code doesnt compile

void setup() {
// put your setup code here, to run once:
Serial.begin(115200);
Serial.println("Hello world");
}

In case its of any use.

I found this on mbed

https://developer.mbed.org/forum/team-6 … pic/17027/

It looks like the Arduino linker settings are definiatly set for the S130 soft device

However it also looks like if we change these (and perhaps some other stuff in the build) we could use the S110 instead which is smaller and takes 2k less ram

@ozan

Just a few more bits of information.

I’m not sure why, but I’m finding it unreliable to just upload the sketch hex file. It seems to be better if I use mergehex (the nordic tool) to merge the sketch hex with the softdevice hex before I upload – but the problem may be my STLink debugger and your JLink may be better.

Strangely, sometimes when I try to merge, I was getting an error like this

ERROR: The hex files cannot be merged since there are conflicts.

More progress

With the help of Rick, we have modified the Black Magic Probe (BMP) firmware so that it works with the nRF51822 modules that I bought from eBay.

The problem was that the modules have the nRF51822 QFAC, which has 32kb RAM and returns a different deviceID when queried by the BMP, so that the original firmware did not recognise the device as a nRF51 and fell back to treating it as a ARM Cortex-M0
The problem with this, is that it wasnt possible to erase the whole flash or even to flash any code to the chip at all.

GDB didn’t give any errors to suggest that Flashing had not occurred, but when I tried to run the code, the old code was still there.

Anyway, with the updated version of the BMP, everything now works fine!

I can directly compile and upload from inside the IDE. All you need to do is select the COM port of the BMP’s GDB port. Note this is a little confusing, as the BMP shows up as 2 Serial devices. One of these is the Serial passthrough port, which I have connected to the Serial TX and RX on my module, the other serial device is the one that needs to be selected, as the IDE uses it to tell GDB which port to with over.

This is a little messy, It may be possible to fix this by writing a plugin for the IDE but I’m not entirely sure of (a) how to do this, and (b) what plugins are capable of doing…

One minor annoyance that still remains is that it takes ages to build.
It takes my moderately fast Core i5 machine over 40 seconds to build a blank sketch, and the IDE does not seem to cache any of the object files, so if you make a minor change and rebuild, it takes over 40 seconds again.

Looking at the build process, it creates a library called core.a from the core files e.g. WString.c but it seems to build this every single time.

So there must be something in the build recipies that is causing it to do this unnecessarily.

But at least it now works

Some useful information about these generic nRF51822 modules

It looks like the modules are sold (and possibly made by WaveShare) and they have a lot of information on their wiki about both the RF module and the motherboard

Items in WaveShare’s shop

http://www.waveshare.com/catalogsearch/ … q=nrf51822

Wiki for the Motherboard http://www.waveshare.com/wiki/NRF51822_ … 2_Software
Wiki for the RF module http://www.waveshare.com/wiki/Core51822

Schematic for the motherboard is here http://www.waveshare.com/w/upload/1/1b/ … ematic.pdf
Schematic for the RF module is here http://www.waveshare.com/w/upload/5/57/ … ematic.pdf

More useful information on the RBL nRF51822 Arduino core..

It looks like the nordic SDK files they use are from mbed

https://mbed.arm.com/teams/Nordic-Semic … 3d5/source

Commits look really up to date, in fact some only got changed a few days ago, so I think this must be compatible with version 9 of the actual nordic SDK.

I have been using V9 of the S130 soft device and it seemed to work fine, with the core.

The downside of RBL using the mbed files is that there is only code for the S130 SoftDevice, which is the larger more full featured of the S100 series.

ideally people should be given the option of using the S110 as it takes 2k less ram, which could be a big deal if they have a 16k RAM rather than 32K ram version of the nRF51822

But I don’t know anything about the way mbed is run and who maintains this stuff.

For anyone interested in actually seeing the Arduino IDE build and upload a sketch into the nRF51822, I’ve done a video

https://www.youtube.com/watch?v=WmCmqN2 … e=youtu.be

I will need to write a complete list of instructions, as I had to gloss over the setup stuff, as the limited version of the screen recorder I’m using, cuts off after 10 mins, and to be honest, I think 10 mins is perfectly long enough for a single video

RogerClark wrote:For anyone interested in actually seeing the Arduino IDE build and upload a sketch into the nRF51822, I’ve done a video

https://www.youtube.com/watch?v=WmCmqN2 … e=youtu.be
<…>

Ray,

Nordic provide precompiled firmware called a Softdevice, which handles all the low level hardware control and Bluetooth protocol stacks, but its not an RTOS like the ESP8266 uses.

There are different Softdevices, depending on how much functionality you need from the Bluetooth. There are 3 different Softdevices for the nRF51822, called the S110,S120 and S130.
The current code from RedBearLab only supports the S130, which is the most full featured version, but takes 2K more ram to run than the S110. (from what I’ve read).

These Softdevices are not linked like a library, you flash them like a bootloader, and they run when the device starts up. However they don’t do much in their startup code, they just do a small amount of pre-initialisation and then call main() in the users code.

The sketch has to call into the Softdevice to initialise it fully and start it working.

After that, the loop() in the sketch seems to need to call ble.waitforevent();

It is possible to run an RTOS, I know several RTOSs were being ported to this platform.

However this is not a high performance device. Ram is only 16k in the base model nRF51822 and I think the Softdevice takes half of that.

Its also not a fast device, as its generally clocked at 16MHz.

But its designed for low power applications, and I think it does them very well.

If you want a new chip to play with this winter; you could do worse than buying a few of those eBay modules, as I’ve seen them as cheap as around $6 on ebay.

The only annoying thing is the physical pin arrangement on the module.
So if you are willing to splash some more cash, those motherboards would make the assembly process a lot neater.

Actually, I’m seriously considering designing a motherboard with a STM32F103 on it to act as the BMP. But I’m not sure when I’d have time to do it

I will post my modified core on github, when i have tidied it up a bit, and If anyone wants a “warts and all” version I will zip it up and stick it on one of my virtual servers.

BTW.

To make things easier…

Rick and I have thought about doing a build of the BMP that runs on Maple mini hardware.

But I also want to have the Maple mini code run like a sketch, i.e have the bootloader run the BMP.

This should not be that hard to achieve, as we just need to move the vector table offsets up a bit, and also tell the linker that it sits at 0x8005000 rather than 0x800000, then you should be able to flash the BMP into a Maple mini over DFU and still be able to get back to running sketches (albeit you’d need to put it into perpetual bootloader to do so)

Update.

I’ve just pushed the updated to the original RebBearLabs repo to my github account.

https://github.com/rogerclarkmelbourne/nRF51822-Arduino

Note. I’ve not touched their structure, so you’d need to download the zip and then copy out the RBL folder from inside arduino-1.6.x/hardware into your hardware folder

RogerClark wrote:Ray,

Nordic provide precompiled firmware called a Softdevice, which handles all the low level hardware control and Bluetooth protocol stacks, but its not an RTOS like the ESP8266 uses.

There are different Softdevices, depending on how much functionality you need from the Bluetooth. There are 3 different Softdevices for the nRF51822, called the S110,S120 and S130.
The current code from RedBearLab only supports the S130, which is the most full featured version, but takes 2K more ram to run than the S110. (from what I’ve read).
<..>
If you want a new chip to play with this winter; you could do worse than buying a few of those eBay modules, as I’ve seen them as cheap as around $6 on ebay.
<…>

Hi Ray

No worries

I want to make the installation process a lot simpler than it was for me. So I agree its best to hold off until Rick and I have ironed out all the creases.

I think Rick has some of the modules on order, and has also ordered the motherboard, in fact he may have ordered a motherboard including the RF module.

Probably getting the BMP working with the Maple Mini and retaining the bootloader is the next thing I need to do.

But also there is a minor annoyance in that on power on the BMP halts the processor.
So I think I need to modify the BMP so that it doesn’t do this.

Increasing the build speed is also something that needs to be sorted out.

There is something a bit strange about the build recipes , which are causing this, and also I cant change the build recipes to make it worth with 1.6.6 as it no longer links.

Apart from the large number of include paths they use, I can’t quite see why I can’t just re-purpose our recipes (or perhaps I can !)

Anyway… Watch this space

RogerClark wrote:But also there is a minor annoyance in that on power on the BMP halts the processor.
So I think I need to modify the BMP so that it doesn’t do this.