Softdevice s140 v6.1.0 Assert 0x000154A2

[kylekubik]

I am currently using softdevice s140 v6.1.0 with my nrf52840 product, and I am occasionally running into a Softdevice Assert located at 0x000154A2 while the device is advertising. The issue is inconsistent but happens enough to be an issue. I haven't been able to find anyone reporting the same issue online, although I've read through many of the posts about the debugger or other issues. I'm not using breakpoints and simply letting the device run on its own while watching with a debugger.

Is there any way to get more information about what specifically is causing the assert? 

[tesc]

Hi,

This usually means that the SoftDevice has been prevented from running interrupts at its priority 0 level. Are you disabling interrupts, or running your own interrupts with priority 0, or somehow directly accessing flash or other peripherals blocked or restricted by the SoftDevice (not possible unless tampering with the MWU peripheral), or doing anything from the debugger that might cause delayed execution on the nRF?

If none of the above, you may have potentially found a flaw in the SoftDevice, in which case we need more details in order to investigate further, preferably a small example that shows the behavior, sniffer traces, and/or logs from the application showing what is going on.

Regards,
Terje

[kylekubik]

Thank you for your response.

• Are you disabling interrupts - We are using the nRF5 SDK for Mesh v3.1.0 which I believe disables some interrupts while it is inside its timeslot.
• running your own interrupts with priority 0 - No, on the nrf52840 we only use priority levels 2, 3, 6, and 7.
• directly accessing flash or other peripherals blocked or restricted by the SoftDevice - no 
• doing anything from the debugger that might cause delayed execution on the nRF? - no

Over the weekend I did some testing and found that changing the Low Frequency clock source from the External Crystal to a Synthesized Clock prevents the issue or at least makes it much less frequent. This leads me to believe it is possibly a hardware issue with our external crystal, so I plan to try swapping it to see if that helps.

I suppose a faulty low frequency clock could cause timeslots to be out of sync and crash into the softdevice's processes?

[tesc]

Hi,

Yes, that could very well explain what is going on. The SoftDevice does a lot of timer checks to ensure proper operation. In the typical cases that I listed, it asserts because operations took too long. It might as well assert if e.g. LF-clock and HF-clock is too much out of sync.

With synthesized clock the sources should be synchronized (as one is synthesized from the other), but please note that the SoftDevice is designed and tested for the options of internal RC Oscillator and external Crystal Oscillator - but not for the synthesized from HF clock option. It may be wise, therefore, to use the internal RC Oscillator option if changing from external oscillator. For details, see the clock source chapter of the SoftDevice Specification.

Regards,
Terje