debugging softdevice applications with gdb

RE: debugging softdevice applications with gdb

Vidar Berg — Wed, 02 Dec 2015 13:45:55 GMT

The application is always reaching the assembly breakpoint you set in main.c when I try it here. Also able to do memory dumps at this point. Have you tried to halt after softdevice init and do instructions steps (ni) to verify that it's stuck in the softdevice (address is below 0x16000)?

RE: debugging softdevice applications with gdb

Jean-Louis Bonnaffé — Tue, 01 Dec 2015 14:34:28 GMT

Confirmed. SoftDevice 7.1.0 @0x16000. The problem is I am getting stack overflows when increasing the RSA key size, and I'd like to estimate the available RAM space at specific points in the program. I am using JLinkGdbServer, setting a breakpoint and continue. If the breakpoint is before softdevice init, I am able to run (gdb) dump memory ram.dump 0x20000000 0x20004000. If the breakpoint is after, the GDB prompt never comes back, and the backtrace shows the exec in hanging in softdevice init.

RE: debugging softdevice applications with gdb

Vidar Berg — Tue, 01 Dec 2015 14:15:54 GMT

Assume it's s110 v.7.x.x as the start address is 0x16000? That said, it was a false alarm regarding the hardfault, somehow the softdevice was being erased after I loaded .elf file earlier, guess it was to late in the evening. Now I'm able to debug the project. It advertises for a couple of seconds and I'm able to connect to it, but could you explain the problem you experience so I have a better idea of what to look for, and also what the expected behavior should be when not using any ext sensors?

RE: debugging softdevice applications with gdb

RK — Tue, 01 Dec 2015 02:35:11 GMT

what softdevice is that code compiled to use? I was going to try running it and see if I can also fail totally to work out what's going on. Is there a reason by the way that you omit the frame pointers? If you do get manage to get gdb hooked into the code at a breakpoint, not having them is going to make it somewhat harder to debug beyond your current stack frame.

RE: debugging softdevice applications with gdb

Vidar Berg — Mon, 30 Nov 2015 15:26:06 GMT

Hi, I'm using the nRF51 DK kit. Tried running your code but it goes into hardfault. Could you send me your project on project on a PM or at mypage so I can try to debug it further?

RE: debugging softdevice applications with gdb

Jean-Louis Bonnaffé — Mon, 30 Nov 2015 15:11:36 GMT

Optimization level is zero. My gcc flags are : -ffunction-sections -mcpu=cortex-m0 -mthumb -mabi=aapcs --std=gnu99 -mfloat-abi=soft -ggdb -O0 -fomit-frame-pointer

RE: debugging softdevice applications with gdb

Wojtek — Mon, 30 Nov 2015 14:53:40 GMT

What is your level of code optimisation? If it is different than 0, try turning it off (to 0). I am also using gdb - it is hard to debug during connections etc, but not impossible.

RE: debugging softdevice applications with gdb

Jean-Louis Bonnaffé — Mon, 30 Nov 2015 14:52:49 GMT

Indeed the softdevice was initialized with NRF_CLOCK_LFCLKSRC_XTAL_50_PPM. However, changing to other values doesn't make a difference. Breakpoints beyond softdevice_handler_init are not reached. Attached ELF for reference (compiled for a nRF51 board, GPIO are remapped). Which refdesign are you using ?

RE: debugging softdevice applications with gdb

Vidar Berg — Tue, 24 Nov 2015 08:12:46 GMT

Does the softdevice init ever return to main context? It will hang in an endless loop within the SD if you've chosen selected the NRF_CLOCK_LFCLKSRC_XTAL_x_PPM enum as the SD will wait for the crystal to start up. LF clock source).

If you are able to share your .out/.elf file with debug symbols I can try to debug it as well and see if I can find some clues (code must work on the nRF51 DK kit).

RE: debugging softdevice applications with gdb

Jean-Louis Bonnaffé — Mon, 23 Nov 2015 15:39:36 GMT

Thanks for the hint. The "RAM painting + breakpoints" seems a valid approach. However, the crux of my problem is I cannot take gdb beyond the SoftDevice init, so I am not able to break, halt, step, etc. Unfortunately, setting PRIMASK doesn't help either.

RE: debugging softdevice applications with gdb

Vidar Berg — Mon, 16 Nov 2015 12:56:38 GMT

Hi, It's not possible to single step while the softdevice is in use as you may know already. That is, you can do it to some extent as explained in this thread. What you can do is to set breakpoints and see if the are reached during program execution. E.g., place a breakpoint in app_error.c->app_error_handler() to see if any of the calls to the softdevice has returned an error code. You can also use trace to log debug data over UART or Segger RTT.

Some suggestions if you suspect stack overflow:

Allocate more stack and see if you still experience problems.
Halt the cpu when you think the stack may have overflown and read the stack pointer (R13) value. Then check against your .map file from the build output and see if the SP is outside the allocated call stack range.
"paint" the ram above the application region with a known pattern at startup, and let the application run for some time. Then halt cpu and read the RAM to determine the max. stack usage.