NRF_FAULT_ID_SD_ASSERT @PC 0x15074

[Manuel Rohrauer]

I'm having an error in my project where the app_error_fault_handler(...) is triggered generating an NRF_FAULT_ID_SD_ASSERT. I've overwritten the function and stored the ID and PC which is 0x01 (NRF_FAULT_ID_SD_ASSERT) and PC@0x15074.

My Hard- & Software setup:

• nRF52840-DK (PCA10056)
• nRF5 SDK v17.0.2
• S140 v7.2.0
• FreeRTOS v10.0.0

In my setup I have

• 24 development boards,
• connected to 4 different masters -
• so each master hast to handle 6 devices.
• The connection interval is fixed @100ms.

I don't know whether the amount of boards is related to the error; maybe only because of more BLE traffic in the area. Unfortunately the error is not quite easy to reproduce and only occurs ever 1-2 days at some boards (different, not the same).

From this post I've learned, that the error can be caused of the application code blocking the softdevice: devzone.nordicsemi.com/.../s140-7-2-0-assert-pc-0x15074

But I've already checked my critialSections and hardware interrupts; I only have one GPIO ISR, with a priority of: GPIOTE_CONFIG_IRQ_PRIORITY 6.

So what kind of code sections can cause such an error?

Is it possible to get more information about the error. I now know the ID and the PC; the "info" field of the app_error_fault_handler(...) unfortunately is 0x00. If I assume that the error is cause from my application code, it would be very helpful to know the function, task or interrupt which caused the error.

I appreciate any kind of help,

Manuel

[Einar Thorsrud]

Hi,

This assert is from an internal module in the SoftDevice that handles radio events, and is caused by an event occurring later than expected, as explained in the other thread you found. The assert does not provide more information about why that happened, but typical reasons are high priority interrupts or long critical sections, which I see you have considered. Another typical issue is that you use a timeslot that does not end on time.

[Manuel Rohrauer]

Hi Einar,

thank you for your quick reply. How exactly can I check if the issue is on the timeslot area. How do I check if it hangs there or it does not end?

[Einar Thorsrud]

Other than keeping track of time you don't really know, so well, you need to keep track of time and ensure you don't overstay it (use resources for longer than allowed).

Another point, which may be far fetched, but it is thinkable that there could be a mismatch between the high frequency clock and low frequency clock (which are independent). If they drift too much from each other you could potentially see problems. What is your 32.768 kHz clock source? To rule this out, you could run with synthesized LF clock, where it is derived form the HF clock. That results in high power consumption, but if you find other reasons unlikely it could be work a test just to check if this could be related or not.

[Manuel Rohrauer]

We are using the external crystal on the DK Board. I'll try the settings for the synchronized clock to rule that out. To changed that; I'll have to change the following settings in sdk_config.h

• NRFX_CLOCK_CONFIG_LF_SRC 2
• CLOCK_CONFIG_LF_SRC 2
• NRF_SDH_CLOCK_LF_SRC 2

Is that correct? I think I don't need both NRFX_CLOCK_CONFIG_LF_SRC & CLOCK_CONFIG_LF_SRC in my file?

Additionally: Let's say the error comes from the clock drift of the external crystal. What about the internal RC oscillator. I'll ask, because the synthesized LF clock needs 100µA and the internal RC 1µA

[Einar Thorsrud]

Hi,

For project that use a SoftDevice you only need to set NRF_SDH_CLOCK_LF_SRC to 2 to use synthesized 32.768 kHz clock. As you are using the crystal oscillator from before this is a bit far fetched, but it could be worth a shot, if only to rule it out.

Have you seen this assert on multiple boards or only one?