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

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

sushil — Mon, 09 Jun 2014 10:48:35 GMT

It seems that link to ble_app_hrs_printf.zip is brokend. Hey Ole, Can you please make it available? Thanx.

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

Chris — Wed, 21 May 2014 06:39:40 GMT

I've got simple UART (the HW UART pins, not running over BLE etc) all up and running, spitting out on my Mac's terminal software etc but I'd love to be able to set it up as stdout so I can just use printf...

Anyone have any instructions on this? I've seen the sprintf into a buffer then calling simple_uart_putstring etc but would prefer just being able to call good ole printf..

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

Ole Morten — Fri, 07 Mar 2014 16:06:55 GMT

Unfortunately, the nRF51822 doesn't have any tracing support, so sending UART-like data over the debug interface is not possible.

The application attached here should work with any nRF51822 with some kind of UART-to-RS232 converter, be it the built-in function of the Segger chips, the converter on the nRFgo motherboard or any other such device.

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

Jason De Lorme — Fri, 07 Mar 2014 16:04:16 GMT

Ole - to be clear, this assumes you are using one of the eval boards (i.e. PCA10001) which has TX/RX pins designated on the nRF51 for UART. Is there a way to redirect printf() to use the debugger interface instead of UART with the J-Link Segger Lite?

For example can you just use (SWDIO & SWCLK) and attach GDB to see printf() commands via stdout in GDB? Does that make sense?

Thank you!

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

Joe Merten — Thu, 06 Mar 2014 21:36:57 GMT

Seems that the attached example not build with the current sdk 5.1.0. I'd also started with the uart example from the sdk instead.

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

Joe Merten — Thu, 06 Mar 2014 13:02:43 GMT

Does this gone further?

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

Ole Morten — Fri, 15 Nov 2013 13:09:02 GMT

To be honest, I haven't tested. If you have trouble with this, I suggest you post a separate question with a little more details, and I can take a look! :)

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

Kyle Gilpin — Wed, 13 Nov 2013 07:59:08 GMT

Ole,

Does the example code you posted work with Eclipse / Sourcery CodeBench Lite? I have attempted to use an identical approach, but the nRF51822 is hard-faulting when I call printf. Tracing this down, it appears that a call within newlib to malloc is responsible. How can I get this working?

Thanks!

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

Ole Morten — Thu, 10 Oct 2013 12:22:21 GMT

No matter if you use GDB or Keil's debugger, you will not be able to keep the BLE link while you're halted on a breakpoint, or keep running softdevice code after having halted on a breakpoint. Doing UART printouts is therefore a very useful addition to hardware debugging, although I do agree that it's very convenient with proper hardware debugging.

As I mentioned above, it is possible to keep debugging application code after having halted, by setting the PRIMASK bit, so in combination with UART prints, this has been sufficient for me.

PS: Personally I'm very happy with GDBs capabilities as well, but Keil is currently (unfortunately) our primary supported toolchain.

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

Janek Mann — Thu, 10 Oct 2013 12:04:31 GMT

Odd to see so many comments regarding using printf for debugging... Sure it's handy sometimes but it's hardly a replacement for a correctly working debugger!

The good news is that gdb works perfectly with the chip including inspecting local variables. And surprisingly gdb these days has some pretty nice features for console "GUI"s too so it's very workable (and much faster than Keil).

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

Jim — Fri, 20 Sep 2013 11:43:46 GMT

Found simple_uart.c in the SDK. It works now.

This was harder to figure out than I would have expected. Maybe a nice app note would be in order?

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

Ole Morten — Fri, 20 Sep 2013 11:42:18 GMT

These are in the simple_uart.c file, in Source\simple_uart. In the project I attached, it should already be included. If you try to use this in your own project, you'll have to include the file manually, by double-clicking one of the folders in the project explorer, navigating to the correct folder and selecting the file.

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

Jim — Fri, 20 Sep 2013 11:39:09 GMT

I'm getting a linker error on simple_uart_config and simple_uart_put. Where are those functions coming from?

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

Ole Morten — Fri, 20 Sep 2013 11:27:29 GMT

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

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

Jim — Fri, 20 Sep 2013 11:25:35 GMT

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.

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

Ole Morten — Fri, 20 Sep 2013 11:05:54 GMT

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

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

Jim — Fri, 20 Sep 2013 10:56:39 GMT

Nils, please clarify:

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

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

Nils Minor — Fri, 20 Sep 2013 10:43:58 GMT

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 ^^