Spurious S110 crash

[Peer]

Dear Support Team,

I'm working on a BLE application and the most stuff works well but now I had a spurious application crash at "src\ll_lm.s0.c: 1038". Could you please check what kind of assertion has been failed here? I was using the 6.0.0.1-alpha S110 softdevice.

Thank you in advance, Peer.

[Anne van Rossum]

This happens to me when I run gdb with for example this breakpoint which normally would hit, print the value, and continue.

b BluetoothLE.h:738
commands
p rssi
c
end

The softdevice crashes subsequently at this location:

Program received signal SIGTRAP, Trace/breakpoint trap.
softdevice_assertion_handler (pc=40722, line_num=783, 
    file_name=0x20001bac "s"...) at ./ble_error.h:34
34	    __asm("BKPT");

This is indeed line 783 in ll_lm.s0.c.

printf "%s\n", file
src\ll_lm.s0.c

Do I have to run gdb with a different priority for its interrupts or something like that? How do I do that?

Code is at github.com/.../bluenet

[Ole Morten]

You can't start running again after having halted on a breakpoint, since the breakpoint ruins the link timing of the softdevice. Take a look at this question for details: https://devzone.nordicsemi.com/index.php/can-i-debug-ble-program#reply-1504

[Anne van Rossum]

@Ole. Ah, thanks. That makes sense.

I wish there was some low-level priority debugging option though. Some kind of gdb option that won't break those real-time properties which you definitely need to run the BLE stack.

[Ole Morten]

I agree that this would have been very useful, but with the current architecture, that's unfortunately not possible; once you halt the program, the connection will break.

[Anne van Rossum]

@Ole. Maybe tracepoints can be supported somewhere in the future...

https://sourceware.org/gdb/onlinedocs/gdb/Tracepoints.html

Would be nice.