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

Receiving an NRF_FAULT_ID_SD_ASSERT error some non-deterministic time after connecting via BLE

I am constantly receiving an NRF_FAULT_ID_SD_ASSERT error within a non-deterministic time after connecting via BLE.

The program Counter is always 75936 and Info == 0. I am using the SDK 14.2 and the softdevice 5.0 (which is not perfectly in line with the compatibility matrix, although I downloaded this configuration in January 2018 "as it is" from your site...).

I enclosed the sdk_config.h, because this was often the the cause of problems in the past.

I would be glad if you could provide me some hints where to look at; hopefully I am able to do the rest.

Thank you in advance, JulianMA.

sdk_config.h

Parents
  • Hi,

    I have seen two previous reports of asserts at that particular address. One of them was due to an incorrectly loaded crystal, and the other one is unfortunately still a mystery. As I wrote in the comments here, your assert indicates that something is messing with the mechanisms that the Softdevice uses to keep time. To keep time, the Softdevice uses RTC0 and TIMER0 and both peripherals use interrupts that run in priority 0 (highest). So the question is how your application is able to disrupt these timing critical things? It could be one of two root causes:

    1. An inaccurate clock causes the nRF52's time to tick too slow or fast relative to the rest of the world.
    2. Something in your application is messing with the Softdevice's RTC and Timer interrupts, preventing them from being executed on time. 

    Some questions:

    1. Can you give us some more details about what kind of application your making?
    2. I understand the assert seems to happen randomly, but is it possible to say anything at all about what the application is doing when the asserts occur? Is it advertising? In a connection? Processing something? Etc..?
    3. Are you using a development kit or a custom PCB?
    4. Are you using a lot of interrupts in your application?
    5. Are you using the time slot API?
    6. Is this happening on more than on device? If so what is the failure rate?
    7. Are you doing flash operations in your application?
    8. Are you at any point disabling interrupts to execute time critical code? (some drivers and libraries in the SDK do this under the hood)

    Please also read through the case I linked to above and see if you can spot some similarities.

Reply
  • Hi,

    I have seen two previous reports of asserts at that particular address. One of them was due to an incorrectly loaded crystal, and the other one is unfortunately still a mystery. As I wrote in the comments here, your assert indicates that something is messing with the mechanisms that the Softdevice uses to keep time. To keep time, the Softdevice uses RTC0 and TIMER0 and both peripherals use interrupts that run in priority 0 (highest). So the question is how your application is able to disrupt these timing critical things? It could be one of two root causes:

    1. An inaccurate clock causes the nRF52's time to tick too slow or fast relative to the rest of the world.
    2. Something in your application is messing with the Softdevice's RTC and Timer interrupts, preventing them from being executed on time. 

    Some questions:

    1. Can you give us some more details about what kind of application your making?
    2. I understand the assert seems to happen randomly, but is it possible to say anything at all about what the application is doing when the asserts occur? Is it advertising? In a connection? Processing something? Etc..?
    3. Are you using a development kit or a custom PCB?
    4. Are you using a lot of interrupts in your application?
    5. Are you using the time slot API?
    6. Is this happening on more than on device? If so what is the failure rate?
    7. Are you doing flash operations in your application?
    8. Are you at any point disabling interrupts to execute time critical code? (some drivers and libraries in the SDK do this under the hood)

    Please also read through the case I linked to above and see if you can spot some similarities.

Children
No Data
Related