S140 7.2.0 assert @ pc: 0x15074

[Benjamin]

I'm getting a strange assert from S140 7.2.0 nRF5_SDK_17.0.2_d674dde on a nRF52840 at PC 0x15074.

Frustratingly, it happens a minute or so after boot, but doesn't occur after a soft reset via debugger. I'm suspecting it's something memory related because I also have a buffer in use by SPIS that is misbehaving after boot, but behaving properly after a soft reset. Any clues to help me find the culprit behind this behavior would be much appreciated.

[Einar Thorsrud]

Hi,

This assert is caused by an event overstaying (did not end by the timeout). A typical reason could be fi you use critical sections for too long or for some other reason prevents the SoftDevice from doing it's work on time.

[Benjamin]

I'm not using any critical sections directly, and I'm fairly certain the only bit of the SDK I'm using that has a critical section is app_scheduler. All the chip is doing is SPI comms (SPIM3 & SPIS2), polling some GPIO, and running a BLE NUS. I have 1 interrupt at priority 2, but that only triggers when RTC2 running at ~1kHz overflows, so that shouldn't be occurring this quickly. All other interrupts are at 6 or 7.

Any idea of what sorts of other things could cause this? Is there a chance my advertising settings or other BLE config could be at fault?

[Benjamin]

This managed to resolve itself with various other code changes. Nothing especially related stood out.

[Einar Thorsrud]

Good to hear that it no longer seems to happen. A high priority interrupt could also cause this if you spend a long time servicing it (or generally anything that prevents SoftDevice interrupts from being serviced in a timely manner). It is difficult to say exactly what triggered it in your firmware though.

[Benjamin]

Is it possible a low priority interrupt that kept the chip from returning to the main thread for long enough could trigger this? Particularly with NRF_SDH_DISPATCH_MODEL 1 (app_scheduler)?

[Einar Thorsrud]

Hi,

No, that should not cause this assert (unless it is causes by an unknown bug). It should either happen if priority 0 interrupts (highest priority) are blocked either by a critical section or another equally high priority interrupt being processed, or if a timeslot has not ended on time.