How to identify reset reason

RE: How to identify reset reason

bloobird0 — Mon, 12 Sep 2016 07:36:48 GMT

Thanks a lot for your support and time.

RE: How to identify reset reason

Stefan Birnir Sverrisson — Mon, 12 Sep 2016 07:32:16 GMT

Softdevice asserts are normal when you use breakpoints. You usually can step through the code until you have a call to the softdevice, then the softdevice will assert. You also can not step into softdevice code. So the way to debug with softdevice is to set a breakpoint and step to the next softdevice call. If you want to debug beond the next softdevice call, then set a breakpoint after the softdevice call and restart program execution.

RE: How to identify reset reason

bloobird0 — Tue, 06 Sep 2016 16:06:39 GMT

Excellent, thanks a lot!

It looks like that the reset is caused by a Softdevice assertion (softdevice_fault_handler is called with id=0x01 and then lead in a NVIC_SystemReset() ).

The Softdevice assertion only happens when using breakpoints. I have read this that tells me that the breakpoints are a potential source.

Does it mean that the usage or breakpoints is useless as soon as the BLE is started (e.g.: only advertising)?

It there a way to look at the reason for a Softdevice assertion?

RE: How to identify reset reason

Petter Myhre — Tue, 06 Sep 2016 15:35:30 GMT

Maybe this is helpful.