RE: How to determine cause of a SoftDevice reset?

Dan Halbert — Mon, 22 Oct 2018 16:42:05 GMT

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

RE: How to determine cause of a SoftDevice reset?

MartinBL — Mon, 22 Oct 2018 16:00:37 GMT

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