• State Not Answered
  • Replies 5 replies
  • Subscribers 73 subscribers
  • Views 2654 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 125799
Options
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

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.

Parents
  • 0

    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?

Reply
  • 0

    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?

Children
No Data
Related
Terms of service