This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

S132 frequent occurrences of NRF_FAULT_ID_SD_ASSERT

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.

Parents
  • 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?

Reply
  • 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?

Children
No Data
Related