I’m loving the debugging capabilities when programming the nRF51822. A great feature of the nRF51 DK is its support for programming and debugging of external nRF51822’s – like the one that will be on the Ladybug Blue Lite. Definitely a YIPPEE moment!! No external SWD debugger is required. If the nRF51 DK did not include a SEGGER J-Link OB debugger chip with debug out functionality, I would have to buy a debugging probe from Segger that cost between $60 to over $1000 (link to website). The nRF51 DK is becoming quite a bargain!
The goal of this post is to make sure the Ladybug Blue Lite has the correct circuitry to support programming and debugging through the nRF51 DK. I will have more confidence in the part of the schematic that handles debugging traffic.
Thanks To Those That Went Before
Mahesh Venkitachalem wrote an extremely useful post on external programming of an nRF51822 chip using the nRF51 DK. Thank you!
And a grateful thanks to Chris Gammell for his Contextual Electronics course as well as his mentorship on electronics – with an emphasis on schematic design, layout, as well as how different circuits work using tools like LTSpice.
The nRF51 support and development team at Nordic for providing a really great forum – the Nordic Developer Zone – where many of my questions were answered. Their support has proven to be quite strong. THANK YOU!
Debugging Pins on the nRF51 DK
The nRF51-DK User’s Guide (download link) points out the connectors P19 and P20 are used in support of external debugging. The pin outs shown in the PCA10028 schematic and PCB document (download link) has the following diagrams for the two connectors:
P19 is the standard Cortex-M 10-pin debug connector. I don’t have one of these cables so I will use the P20 connector. As noted by Mahesh in his post, the P20 connector uses the 2.54mm pin spacing that makes it easy to hook up with breadboard wires I already have. Looking at the layout (image from Mahesh’s post):
Pin 8 is close to R10 and R9. Pin 1 is closes to current measurement.
I’ll use Adafruit’s Bluefruit LE UART Friend for the external nRF51822 that I will program (or debug) to. The back of the board expose pads for external SWD debugging:
There are four connections that must be made between an external nRF51822 and the nRF51 DK for SWD debugging:
- Two connections are for SWD debugging traffic. SWD debugging traffic goes over SWD (data i/o) and SWDCLK (clock).
- A 3V reference is required. If the nRF51 DK detects the 3V power coming from the external nRF51822, it will target programming/debugging on the external nRF51822.
- GND is required so that the chips share a common ground.
The Bluefruit exposes the SWD, SWC (clock), and 3V on the back. The GND connection is exposed with the other available connections on the front.
The pin mappings from the P20 connector on the nRF51 DK and the Bluefruit are listed in the table below:
Here is an image of the Bluefruit I used with wires I soldered on:
Here is an image of the Bluefruit connected up on a breadboard:
An an image of the wires connected to the P20 on the nRF51 DK:
Notice the lit LED in the image of the Bluefruit on a breadboard. To test external programming/debugging, I wrote an app for the nRF51822 that turns on and off this light. The Eclipse project – BlinkyBlueFruit – is located at this GitHub location.
Looking at the Bluefruit LE UART Friend schematic:
pins 18 and 19 of the nRF51822 on the Bluefruit have LEDs attached. I’ll use pin 19. Here are the lines in main.c:
// Toggle LEDs.
I’m thankful to Mahesh for pointing out checking the memory allocation for the nRF518122’s Flash and Ram in his blog post. How much is allocated and it’s starting address are contained within the .ld file. The .ld file comes along with each nRF51 SDK example and is part of the Make toolchain. Where there is a Makefile there is a .ld file. I discussed using nRF51 SDK projects in Eclipse in a previous post.
The chip that is being debugged needs to have the origin and length set correctly within the .ld file. These values will vary based on the amount of Flash/Ram on the chip and whether a BLE software stack, like the S110 is used (link to S110 specification download).
Flash and Ram
Since I evolve my software from the SDK example, the first question is: Is there a difference in the amount of Flash and/or Ram on the nRF51822 chip used on the Bluefruit versus used on the nRF51 chip used on the nRF51 DK?
The Flash and Ram of the two chips:
Both the chip on the nRF51 DK and the Bluefruit include 256KB of Flash and 32KB of Ram.
Memory Without the S110 Stack – nRF51 DK
Without the S110 stack, (usually 🙂 ) an .ld file from the nRF51 SDK sets the Flash and Ram memory to:
FLASH (rx) : ORIGIN = 0x0, LENGTH = 0x40000
RAM (rwx) : ORIGIN = 0x20000000, LENGTH = 0x8000
I copied the above from the simple_adc_gcc_nrf51.ld file. The amount of Flash = 0x40000 = 256KB. The amount of Ram = 0x8000 = 32KB.
Memory With the S110 Stack – nRF51 DK
When BLE is added to the software, the values in the .ld file need to accommodate the Flash and Ram used by the BLE stack. I use the S110 stack. Here is a .ld file when the S110 stack is included:
FLASH (rx) : ORIGIN = 0x18000, LENGTH = 0x28000
RAM (rwx) : ORIGIN = 0x20002000, LENGTH = 0x6000
When the S110 stack is present, the Ram origin is set at 0x20002000, length = 24KB (i.e.: 0x6000 length). Note: Table 2 in the S110 Stack specification (link to download) states the S110 takes 8KB of Ram. 24KB + 8KB = 32KB. That adds up nicely!
Based on what I read in Table 2, I thought the Flash origin would be 0x14000 (i.e.: 80KB for the S110 stack). However, the example starts the Flash memory location for the app at 0x18000 – 96KB above 0x0. Maybe this is so the S110 versions have room to grow? Of course – I might be misinterpretting because I am not understanding something.
I set up and used the same erase/flash make commands that I had used previously (see earlier discussion of setting up the Eclipse build environment).
It worked! I have more confidence in what connections are needed on the Ladybug Blue Lite to support SWD debugging. A definite YIPPEE!!! moment.
Thanks for reading this far. Please find many things to smile about.