How to determine cause of a SoftDevice reset?

[Dan Halbert]

I trying to debug an interaction between using SPIM3 on the nRF52840 and the BLE stack in the SoftDevice. A reset is happening, which I think is being generated by the SoftDevice, maybe due to an assertion or timeout failure. But how I do find out the cause? Ideally I'd like to catch the reset before it happens and get a stack trace into my code. I've searched DevZone for techniques and tried to set breakpoints on various handlers, and haven't found anything that works.

Is there a way to do this? I'm using nrfx only, not the SDK, with gcc, gdb, and the built-in PCA10056 J-Link.

The RESETREAS registers reports it as a RESETPIN reset, which seems odd. A colleague has suggested that maybe our code is trying to access the SD's reserved RAM region by accident. Is it protected via the MPU?

[MartinBL]

Hi,

The Softdevice never resets your application. To catch asserts you should check the return code of all Softdevice API calls. Have you implemented some sort of error handler? As I mentioned in the other thread, this is normally done with the Error module in our SDK. Timeouts should be reported to your application through BLE events from the Softdevice. 

Your colleague is correct in that the Softdevice protects its portion of RAM and if you try to access it you will get undefined behavior. I don't think you should get RESETPIN as reset reason in this case though. 

What PCA10056 version do you use?

How do you configure SPIM3? What kind of frequency etc.?

[Dan Halbert]

Thanks - you've answered my misconception about resets from the SD. I can close this case.

We're using the DK PCA10056 with the Rev 1 chip, not the pre-production chip. The SPIM3 frequency does not seem to matter. I set it as low as possible, and the reset still happens. What's odd is that the reset happens when we try to send data via SPIM3, not when we try to do a BLE operation. If we use SPIM2 instead, it works fine

I'll work up a test case that doesn't involve Python code and open a new case with a better title. You can see schematically what's going on here in the Python code, but it doesn't tell you the details of the nrfx and SD calls:

import board,busio,ubluepy
p = ubluepy.Peripheral()        # Set a a BLE peripheral
p.advertise()                          # start advertising. If this is removed, no crash.
spi = busio.SPI(board.D0, board.D1)     # Set up SPIM3 on P!.01 and P1.02
spi.try_lock()                         # internal locking - unrelated to SD or nrfx
#spi.configure(baudrate=1000)        # tried various baudrates - no change
spi.write('AB')                       # reset happens when spim xfer happens