Can Nordic please document how to debug code on their processors?

[Jim]

I love this part (the 51822) so far. Really. However, it really lacks in the debug support department.

Keil is a passable tool. Certainly not state of the art, but I can pinch my nose and use it.

That is, if it worked. When I hit a breakpoint I am unable to see local variables. Seeing local variables is kind of why you might want to put a break point in there in the first place.

But hey, the softdevice is going to lose it's mind if you break for too long anyway, so this method is only useful for last-chance debug. I could live with that if I at least had the most basic form of debugging available.

So, the Jlink-lite device is supposed to permit console output, as described in the evaluation kit overview:

[i]"and a Segger J-Link device which enables program, debug and UART communication with the nRF51822 device over USB." [/i] Other than a post from someone who appears to have jiggled his system to get printfs to work (didn't work for me), I can't find anything that tells me how to get console output out of this device.

Embedded development without even printf debugging is like feeling around in the dark.

Again, if I'm blind and have missed something obvious, please enlighten me.

[Nils Minor]

• Embedded development without even printf debugging is like feeling
• around in the dark. If you mean you want to do some printf while the processor is running you can use the uart modul of the chip and prints uart messages. I use the evalboard and uart Prints in my Com port for the runtime ^^

[Jim]

Nils, please clarify:

1. are you using BLE and the soft device?
2. are you talking about a separate connection to the nrf51822's UART or communication through the SEGGER?

[Ole Morten]

There shouldn't be any problems with using UART for printouts, even when the softdevice is active. See the attached zip for an example of how to add this to the ble_app_hrs for PCA10001. It uses a baud rate of 38400 bps, and uses the Segger chip to transmit the UART data to the PC. Please note that this is a very naive implementation, that will keep the UART on at all times, causing high current consumption. However, it should be very usable for debugging and development.

Unfortunately, Keil seems a little aggressive about optimizing out variables, leading to a lot of "out of scope" variables when debugging. Making sure the optimization level is set to 0 in the target options helps (this is not the default), but even then you might see this kind of errors in some cases.

Also, it is possible to make single stepping after having halted on a breakpoint work, as long as you don't step back into a softdevice function. The connection will however be broken, but this at least enables you to look at your own code. Take a look at this question for an explanation of this, especially Øyvind's answer.

Edit: Add baud rate used.

ble_app_hrs_printf.zip

[Jim]

You're leaving out some important details about the UART. I've got hyperterm connected to the J-link virual com port (COM4 for me) and I'm seeing nothing. What baud rate should I be using?

Optimization removing variables makes sense. I'll try that. Thanks.

[Ole Morten]

Sorry, I forgot. It uses simple_uart's default baud rate, 38400 bps.