S132 frequent occurrences of NRF_FAULT_ID_SD_ASSERT

[Mike Voytovich]

Hi,

We have some devices in the field, and I'm occasionally seeing reboots due to NRF_FAULT_ID_SD_ASSERT. I'm logging the id and pc passed into app_error_fault_handler() and seeing this:

id: 0x00000001 pc: 0x000126c0

Would anyone have some clues as to why the SoftDevice might assert with the PC set to 0x000126c0? We're using S132 5.0.0-3.alpha.

[MartinBL]

Hi, A few questions:

1. Are you using the Timeslot API?
2. Can you elaborate a bit around your application and what state it is in when the assert occurs?
3. Is the application e.g. working in multiple roles? E.g. advertising while connected etc.
4. What SDK are you using?

[Mike Voytovich]

Hi Martin,

1. No, we are not using the Timeslot API.
2. Our application scans for advertisements, broadcasts, utilizes 2 SPI buses for a serial flash and power monitoring chip, I2C for a couple of sensors, GPIOs for buttons, and PWM for LEDs. I'm not exactly sure the precise state when the assert occurs, other than it's in the normal operating mode of doing all of these things.
3. Yes, it does advertise while connected (although, I don't believe I've seen the assert occur during a connection).
4. We're using SDK V13.

[MartinBL]

Thanks.

1. Do you have any interrupts running at priority level 0? Actually, are you using interrupts at all, and what priority levels do they use?
2. Do you at any point disable global interrupts?

[Mike Voytovich]

Thanks for following up Martin!

1. Our sdk_config.h sets all XXX_CONFIG_IRQ_PRIORITY to 7 (the default). We do set APP_IRQ_PRIORITY_HIGH for our I2C driver, but I'm assuming you are referring to the priorities in sdk_config.h?
2. No, we don't (intentionally) disable global interrupts in the app. We do make a call to CRITICAL_REGION_ENTER() to prevent a race condition writing to a FIFO, but only for a few instructions, and I don't believe this code path is possible when we've seen this assert.

Is the SoftDevice PC when this assert hits related to an issue with interrupts?

[MartinBL]

Ok, none of that should be a problem in itself.

Regarding the assert with respect to interrupts, what seems to happen is that something is preventing the Softdevice from executing tasks on time. This could e.g. be due to application interrupts running at equal or higher priority than allowed when using a softdevice.

I noticed that you are using SDK 13 and S132 v5 alpha. Those two are not compatible according to the compatibility matrix. I guess you might port the API to make it work, but they are not tested together by us and hence, not guaranteed to work. Any chance you can stick to the compatibility matrix? Either upgrade to SDK 14 or downgrade to S132 v4?