This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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

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.

Parents
  • 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).

Reply
  • 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).

Children
  • 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.

Related