SIGTRAP on sd_softdevice_enable

[nrbrook]

I'm compiling a custom application using the CMake scripts in the nRF mesh SDK. The first time I flash to the nRF52832 a SIGTRAP occurs on sd_softdevice_enable. I cannot continue from this. If I flash again, it does not occur. Any idea what might be happening, or how I can prevent this?

See also related issue https://devzone.nordicsemi.com/f/nordic-q-a/50709/breakpoints-not-being-hit

I'm wondering if when this SIGTRAP occurs, it is because the softdevice is missing, but breakpoints work because the breakpoint address is being set relative to flash start. When the softdevice is present the SIGTRAP does not occur but breakpoints do not work because they are still relative to flash start not to application start, so land somewhere in the softdevice.

So if I'm correct, that leads to two questions: Why is the softdevice not being written on first flash, and how do I offset breakpoints by the softdevice length?

[Vidar Berg]

Hi,

The Softdevice must be programmed at least partially for the program execution to reach the main app. I remember seeing similar issues before with Segger embedded Studio where a fault exception gets triggered on sd_ enable, but then it has been related to debugger configuration. Maybe you can try to just reset the device instead of flashing it again, then read out the CPU registers to see if the fault also gets triggered when you're not debugging with GDB. 

The "nrfjprog --readregs" command will read out the CPU registers where the last byte of xPSR will tell you the current interrupt number (=3 if hardfault =0 if none).  

[nrbrook]

This also happens in Ozone:

When in this state, running the command gives:

 

$ nrfjprog --readregs
R0:   0x00000010
R1:   0x2000FFB0
R2:   0xA801BE2C
R3:   0xA801BE00
R4:   0x2000445C
R5:   0x00000000
R6:   0x00000000
R7:   0x00000000
R8:   0x00000000
R9:   0x00000000
R10:  0x20000000
R11:  0x00000000
R12:  0x00000000
SP:   0x2000FF90
LR:   0xFFFFFFF1
PC:   0x00000A64
xPSR: 0x81000003
MSP:  0x2000FF90
PSP:  0x00000000

Resetting and running again:

$ nrfjprog --reset
Applying system reset.
Run.
$ nrfjprog --readregs
R0:   0x00000000
R1:   0x00000001
R2:   0x00000000
R3:   0x01010001
R4:   0x00004001
R5:   0x2000FFC8
R6:   0x00027D7D
R7:   0x00040001
R8:   0x00000004
R9:   0x00000000
R10:  0x20000000
R11:  0x00000000
R12:  0x00000000
SP:   0x2000FFA0
LR:   0x0002EBE5
PC:   0x00029D14
xPSR: 0x21000000
MSP:  0x2000FFA0
PSP:  0x00000000

Does this mean the hardfault is not occurring when running without the debugger?

[Vidar Berg]

I was able to replicate this here. Ozone use debugger commands to manually set the SP and PC register with the values from the application's vector table. This breaks the normal startup sequence and the Softdevice's reset handler will not get executed.

Please try to comment out the declaration of AfterTargetReset() and AfterTargetDownload() in your ozone project file (*.jdebug). That should fix the problem. 

[nrbrook]

Yes! That worked. Is there a similar solution for GDB?

[Vidar Berg]

I haven't had this problem with GDB. Are there some GDB scripts included in the Mesh SDK? 

How I usually start a debug session with GDB without .gdbinit:

1. Start the Jlink GDB server

2. Open a new terminal and run "arm-none-eabi-gdb <app>.elf

(gdb) target remote localhost:2331

(gdb) b main

(gdb) c