Troubleshooting SoftDevice assertion

[Paolo D]

Hello, I am working on an nRF52 project that uses the SoftDevice S132 v3.0.0. The system supports BLE observer, BLE central, and ESB functions. BLE central and observer work simultaneously, and BLE central and ESB work simultaneously. However when I try to run all three of these functions simultaneously I get a SoftDevice assertion at PC=0x00011150. With a short scan interval for the observer, the crash occurs immediately, but with a longer scan interval it takes a few seconds to crash. So I assume it's a timing problem.

Is there any information available about why this specific SoftDevice assertion occurs, that I could use to start figuring out how to troubleshoot this? Thanks, Paolo

[Paolo D]

There are no flash operations executing while I am testing. I haven't tried modifying the BLE+ESB example yet.

It looks like it's definitely a timing issue. If I set both the connection interval and scan interval to 250ms with a 60ms scan interval, it seems to work. But If I change the scan interval from 250ms to 249.375ms (so that a scan event and connection event will eventually collide) it will eventually crash. If I change the scan interval to 248.75ms, the collision and crash happens sooner. I haven't done enough testing yet to know if setting the scan and connection intervals equal really fixes the problem, or if it just makes it much less likely to occur.

[Hung Bui]

@Paolo: It would be much easier to trace down (and narrow down) the problem if you can provide a simplified project that can demonstrate the issue so we can reproduce here. Would prefer to use the example I suggested as the base project.

[Paolo D]

I think I've found and fixed the problem. At the start of each timeslot I enable TIMER0 COMPARE interrupts 0, 1, and 2. However at the end of each timeslot I was never disabling these interrupts. If I disable those interrupts with INTENCLR in the TIMER0 interrupt handler before the timeslot ends, then everything works reliably.

I don't know if the crash occurs because a TIMER0 interrupt is occurring outside of my timeslot when the SoftDevice isn't expecting it, or if the SoftDevice just isn't expecting to find those interrupts enabled. Either way it's fixed now. Thanks for your help.

[Hung Bui]

I'm glad that the issue was found, Paolo :) It's true that the softdevice wouldn't expect the TIMER0 interrupt to be enabled and reconfigure all registers. I assume that the softdevice only configure the register that it uses leaving some of the untouched. What we stated in the doc is that the application should returns the TIMER0 and RADIO as it in the state when receives from softdevice. I think it's included that COMPARE interrupts should be disabled. I will try to report internally, we should mention something about this in the documentation.

[EDITED] Actually it's already stated in the release note of S132 v3.0 : If the application uses TIMER0 inside a timeslot (scheduled with the Radio Timeslot API), INTENSET for TIMER0 must be cleared before the timeslot ends (DRGN-7776)

[Susheel Nuguru]

wow, this is very interesting. I also thought that app can leave its settings on these peripherals and softdevice will re-initialize them completely. Time to read the release notes again carefully :)