Spurious S110 crash

RE: Spurious S110 crash

Anne van Rossum — Fri, 21 Feb 2014 12:24:35 GMT

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

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

Would be nice.

RE: Spurious S110 crash

Ole Morten — Fri, 21 Feb 2014 11:59:12 GMT

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.

RE: Spurious S110 crash

Anne van Rossum — Fri, 21 Feb 2014 11:57:25 GMT

@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.

RE: Spurious S110 crash

Ole Morten — Fri, 21 Feb 2014 11:46:00 GMT

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

RE: Spurious S110 crash

Anne van Rossum — Fri, 21 Feb 2014 11:43:52 GMT

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

RE: Spurious S110 crash

Ole Morten — Tue, 12 Nov 2013 12:24:20 GMT

I'm sorry for the late response, but what priority level does your UART interrupt run with? When the softdevice is enabled, you should always make sure to use the sd_nvic_* functions, so that you don't accidentally use an illegal interrupt priority.

If you still have problems, I'd be very happy if I could get to look at your complete source code.

RE: Spurious S110 crash

Bastiaan — Tue, 29 Oct 2013 21:30:17 GMT

I am experiencing the same problem, reproducible by transmitting and receiving data over the UART. Eventually the error will occur, causing a fault to be asserted.

Debugger says the failure is occurring at line

src\ll_lm.s0.c: 783

RE: Spurious S110 crash

Guest — Tue, 29 Oct 2013 21:30:17 GMT

I am experiencing the same problem, reproducible by transmitting and receiving data over the UART. Eventually the error will occur, causing a fault to be asserted.

Debugger says the failure is occurring at line

src\ll_lm.s0.c: 783

RE: Spurious S110 crash

Guest — Sat, 26 Oct 2013 15:09:25 GMT

Ok, the problem occured reproducable in a bit different manner: src\ll_lm.s0.c: 783 Code: 48879 Occurs everytime when I delegate an irq handler (UART0) to a c++ method like: gpApp->mainMCUService.isrUARTRcv(NRF_UART0->RXD);

The line numbers are sometimes different in src\ll_lm.s0.c. I also use c++ delegates together with the timer framework (app_common/timer.c) without no problems or do you see there can be a association with the previous error? The c++ methods are very small (and fast). Maybe a stack problem?

RE: Spurious S110 crash

Bastiaan — Sat, 26 Oct 2013 15:09:25 GMT

RE: Spurious S110 crash

Ole Morten — Mon, 21 Oct 2013 12:30:28 GMT

This fix is unfortunately not yet included in a public release. However, if you can, please submit your code in a support case here: https://www.nordicsemi.com/eng/supportcase/create

RE: Spurious S110 crash

Peer — Mon, 21 Oct 2013 12:24:48 GMT

The problem occured only twice within two weeks (one time with the usb breakout board and once with my custom board. Currently I'm not able to reproduce it all. It occured after a relatively long time of successfully operation with only a few BLE attribute changes / connect / disconnect events from host side.

If I understood you correctly there is a chance that the most recent version of the Softdevice already fixes this (issue)? If you wan't I could share the my sources. (In a non-public way). Please tell me where to submit the stuff. 'P

RE: Spurious S110 crash

Ole Morten — Mon, 21 Oct 2013 12:09:18 GMT

Do you have an application that consistently triggers this assert? If so, I'd be happy to have a look at the source code and trying to replicate it. If you don't want to share the source code here in public, feel free to post a support case and include it there. Any code submitted there is handled in confidentiality.

If this issue only occurs seldom, this could already be covered by a recent fix for a race condition, that will be included in an upcoming softdevice release.