S140 7.2.0 assert @ pc: 0x15074

RE: S140 7.2.0 assert @ pc: 0x15074

Einar Thorsrud — Wed, 10 Feb 2021 08:25:25 GMT

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.

RE: S140 7.2.0 assert @ pc: 0x15074

Benjamin — Tue, 09 Feb 2021 03:26:14 GMT

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)?

RE: S140 7.2.0 assert @ pc: 0x15074

Einar Thorsrud — Mon, 08 Feb 2021 08:16:02 GMT

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.

RE: S140 7.2.0 assert @ pc: 0x15074

Benjamin — Sat, 06 Feb 2021 18:28:08 GMT

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

RE: S140 7.2.0 assert @ pc: 0x15074

Benjamin — Sat, 06 Feb 2021 01:02:42 GMT

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?

RE: S140 7.2.0 assert @ pc: 0x15074

Einar Thorsrud — Thu, 04 Feb 2021 11:41:29 GMT

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.