Arduino on Nordic BLE nRF51822

BTW

My version of the RBL version is now here

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

Note its the S130 branch

More snippets of information

This is a link to the Nordic product selector matrix for the nRF51

http://www.nordicsemi.com/eng/content/d … x_v2.1.pdf

It shows the part number, Hardware ID and RAM and Flash size.

I think the current nRF51.c file in the BMP is not totally correct, in terms of both flash size and RAM size, as it sets virtually all variants to 256k flash and 16k RAM.

If I get time I’ll fix this

Strangeness with SWD lines causing reset

I thought I’d post an update to my issue with the board not running on powerup.

I found this posting on the Nordic site

https://devzone.nordicsemi.com/question … ble-reset/

As far as I can tell, they are implying that the SDIO line also acts as a reset. This seems to be corroborated looking at the schematic for the Waveshare “motherboard” which appears to have a push button that connects SDIO to GND, and as far as I can tell, looking at the picture of the board, the button is labelled “Reset”

So..

The strange thing, is Why am I the only one who has this problem when using the Black Magic Probe, as the normal init code in the BMP drives both SDIO and SCK low in platform.c init()

Perhaps most ARM boards don’t care the default state of SDIO but it appears that the nRF51 does care and it needs to be high

Edit.

I also found this which states the SWDIO line doubles up as the reset line

https://devzone.nordicsemi.com/question … -nrf51822/

monitor erase_mass needed to be used

I’m not precisely sure what happened to get my nRf51 board into this configuration, but I ended up needing to manually use monitor erase_mass before I could get it working again.

I’d been experimenting with various things.. 3 different BMP boards, (a GD32 board, a Red Pill STM32f103C8 and a Maple mini STM32f103CB)
And I had also tried flashing some precompiled firmware to make the nRF51 into a BLE packet sniffer.

Anyway, Uploads from the IDE seemed to hang and code would not get uploaded and run.
I tried manually uploading the code and manually replacing the S130 Softdevice, but to no avail.

i tried flashing RBL’s bootloader hex, which I know instantly should appear as a DFU device on BLE, and that did not work either.

So I used monitor erase_mass to clear the whole MCU, re uploaded the RBL bootloader, and immediately, the DFU device appeared on BLE.

So I reflashed the S130 Softdevice, and uploaded Blink again, and all was right with the world.

So the moral of the story….

If things stop working and don’t make any sense… Erase the whole device, and reinstate the S130 Softdevice.

I’ve finally managed to do the first post to by blog about how to develop for the nRF51822 using the Arduino IDE and a Maple mini as a SWD (Black Magic Probe) programmer

http://www.rogerclark.net/arduino-on-th … ontroller/

I’ve also updated my github repo for this today, by adding a new branch S130_corelib, which vastly speeds to build times, and also fixes an issue with uploads on Linux and OSX

I gave your repo a try. I have one of those BLE400 boards (From Waveshare). It has slightly different pin mappings compared to the RedBear Labs stuff. However, the way RedBear Labs did the pin mapping forces you to modify the core files for a new variant.

nRF51822-Arduino/arduino-1.6.x/hardware/RBL/RBL_nRF51822/cores/RBL_nRF51822/pin_transform.cpp

Seems like you should be able to create a pin mapping without touching the core .cpp files.

-rick

Hi Rick

I didn’t change the pin mapping because I tought the Waveshare board was basically the same as the RBL board.

But my “motherboard” has still not arrived, so it’s difficult to sort this out until it does.

From what I recall, RBLs pins for Serial are not the same as Nordic use on their evaluation board, but was the same as Waveshare. RBL used P9 and P11 but I think Nordic use either 0 and 1 or 1 and 2

I don’t especially like the way RBL coded the pin mapping in a switch statement, and like you say, it needs to be moved into the variant.

I had overlooked this when I moved all the core and variant code into the corelib, but it’s not a big deal to remove the variant code back out if there.

I was initially not intending to use a corelib.a as I had hoped to fix the issue in platform.txt which was not caching the objects, but although I found a few errors in platform.txt; fixing them did not resolve the failure to cache.

Btw.
I managed to get my JLink working with this as well, but I will need to write an upload script, as the JLink CLI needs an external command file, as it can’t be scripted using multiple arguments like gab can

My nrf51822 boards arrived finally, equipped with QFAAH0 chips (3rd IC revision, 16kB ram and 256 kB flash).
1. BMP (uses Baite maple mini) works fine, no problems with flashing
2. Arduino 1.6.5 has no problems with compilation and upload (selected QFAA variant), no errors or warnings.
BUT the only thing that works is RedBearLabs bootloader- DFU device is visible.
All example sketches are not working, module does not advertise and there is no communication over serial.
I’ve searched nordicsemi.com and compatibility matrix says my IC is compatible only with s110 softdevice, how complicated would be to use it instead of s130?

What board do you have

and…

Did you flash the S130 soft device to the board?

RogerClark wrote:What board do you have

The Simple Chat example worked for me, and the scanner example worked.

Bizarrely, I think Blinky will run even if the S130 soft device is missing. ( though I could be wrong as its been a while since I remember this happening)

I have seen wierd things happen if there is a fault with the 32kHz crystal ( which is unlikely in your case)
Someone gave me some 32khz crystals to use with another mRF51822 module, and Blinky worked, but the BLE stuff was very flakey and kept immediately disconnecting.
Anyway, when I looked closely, the crystals were 38hhz not 32.768khz

I also got similar issues when using a 32khz crystal without any 12pF capacitors.

but again, I doubt thats the issue unless you have a faulty module.

Do you have a spare module that you could try, in case its one of these hardware issues.
PS. did you post a comment to my blog?
I notice there is a comment waiting for moderation, on a similar topic

RogerClark wrote:The Simple Chat example worked for me, and the scanner example worked.

Bizarrely, I think Blinky will run even if the S130 soft device is missing. ( though I could be wrong as its been a while since I remember this happening)

I have seen wierd things happen if there is a fault with the 32kHz crystal ( which is unlikely in your case)
Someone gave me some 32khz crystals to use with another mRF51822 module, and Blinky worked, but the BLE stuff was very flakey and kept immediately disconnecting.
Anyway, when I looked closely, the crystals were 38hhz not 32.768khz

I also got similar issues when using a 32khz crystal without any 12pF capacitors.

but again, I doubt thats the issue unless you have a faulty module.

Is is possible to flash or erase only ‘app’ flash region using BMP?

The BMP upload only flashes the App bit

I think mbed combines the softdevice with the code, which makes it much bigger.
(Nordic also do this in their examples, I think they use some code called MergeHex (or something like that))

But there is no need to replace the whole lot each time.

I wonder if its the SoftDevice version. I know that Nordic released newer versions of the S130 a month two ago.

I’ve attached the SoftDevice that I was using.

Re: Blog

No. Someone else seems to have some upload issues. Not sure what it is, the BMP seems to hang. Possibly a device ID issue (no idea at the moment really)

RogerClark wrote:The BMP upload only flashes the App bit

Erase mass does erase the whole device

But the upload script in platform.txt doesn’t use erase mass, I think it uses load file (sorry i cant remember the exact syntax)

Re:RBL

they just upload the app via the co processor or via BLE DFU ( their bootloader includes BLE DFU, however I found it a pain to upload as I had transfer to an android device and them use a Nordic test app to upload via BLE DFU, its much easier via BMP or JLink)

I’ve read through the FAQ and some of the threads here but haven’t found anything relating to this issue yet:
I’ve successfully (I think) made the Maple mini into a BMP.
Just stuck on GDB/ softdevice:

COM ports are recognised in Windows Device Manager as:
COM3 ( Silicon Labs CP210x USB to UART Bridge)
COM4 (Black Magic GDB Server)
COM5 (Black Magic UART Port)

GDB only recognises COM3. For COM4 it returns: ” \.\com4: No such file or directory”. Same with COM5.

Trying COM3 (out of interest) returns:”
Remote debugging using \\.\com3
Ignoring packet error, continuing…
warning: unrecognized item “timeout” in “qSupp
Ignoring packet error, continuing…
Remote replied unexpectedly to ‘vMustReplyEmpt
“monitor” command not supported by this target
Don’t know how to attach. Try “help target”.
”

Before trying the softdevice step (in Roger’s guide on his blog), I tried to upload a Blink sketch from Arduino IDE. I managed to get the console to return:
“Target voltage not Implemented!
Available targets:
No. Att Driver
1 Nordic nRF51 0x0084”

Obviously, it didn’t upload at all but that’s as far as I’ve gotten.
Since then whenever I try to upload the sketch, the Arduino IDE just stays at halfway through upload showing errors in the console.

I’ve set everything up on Windows 8.1 , but am very comfortable in Linux/ Shell if it’s easier/more likely to work.

I think my wiring is correct:
NRF51 slotted into motherboard.
Motherboard connected to Maple Mini (tried switching the SWD SWIO wires multiple times just in case,to no avail).
USB from pc to motherboard for power.
USB from pc to Maple Mini.
I don’t have the UART connected to the Mini (although I think I did try, to no avail).

My QF version is ACA1.

Hopefully my NRF51 is not dead.

Thanks,

Avi

nRF51 is not dead if GDB reads

Nordic nRF51 0x0084

As it gets the chip ID from the nRF51 and checks it against a list to display that message

Remote debugging using \\.\com3
Ignoring packet error, continuing…

is strange

I’ve not seen that before

You could try contacting Gareth (who writes the BMP) via gitter or via a github issue (I think gitter is the best place to start as its less formal than posting a issue for this question)

Thanks very much for suggesting Gareth. I will ask and hopefully report back here when/if it gets resolved.

I should point out that GDB never read:

Nordic nRF51 0x0084

That only appeared once, ever, in the Arduino IDE terminal output when I tried uploading a sketch, before I’d installed GDB properly (I think it
was on my system before from Android Studio/Eclipse or one of the many suites installed…). Arduino IDE probably uses GDB in some way anyway (?).

Could it be that

Remote debugging using \\.\com3
Ignoring packet error, continuing…

is appearing because COM3 is not the GDB server (COM4 is) ?

Was thinking of starting procedure again from scratch as last resort.

Cheers for the support as always.

The Arduino IDE uses GDB to upload.
I use the command written my Rick Kimball ( on this site) for the STM32 upload using GDB.

Its just the commands to connect and scan and uoload, rolled into a single command line.

You should not see errors when you run the target extended remote.
I would also try a different usb port or a shorter cable in this case

hi roger

i got mesmerised by your video on youtube on nRF51822
https://www.youtube.com/watch?v=WmCmqN2i_Xo

& took the bait & ordered this
http://www.ebay.com/itm/201652571766
the competition of making nRF51822 boards seemed to be heating up
if the search is made for nrf51822 on ebay, low prices actually hit usd3.50 ea, i chose the above as it has more of the gpio pins broken out
http://www.ebay.com/sch/i.html?_from=R4 … 22&_sop=15

some of these are apparently from co Wireless-Tag, the great thing is that the board specs are rather well published on the page
http://www.wireless-tag.com/index.php/p … is/26.html
http://www.wireless-tag.com/index.php/p … is/25.html

i’d guess we’d soon need to add this as a ‘board’ in its own ‘sub board forum’ never mind it is not stm32 it is cortex-m & pretty much open platform
it seemed st is trying to make something similar with stm32 hopefully that’d reach mass mkt soon
blinky now goes BLE