Troubleshooting SoftDevice assertion

RE: Troubleshooting SoftDevice assertion

Susheel Nuguru — Thu, 24 Nov 2016 22:06:21 GMT

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

RE: Troubleshooting SoftDevice assertion

Hung Bui — Wed, 23 Nov 2016 09:13:38 GMT

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)

RE: Troubleshooting SoftDevice assertion

Paolo D — Tue, 22 Nov 2016 16:38:50 GMT

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.

RE: Troubleshooting SoftDevice assertion

Hung Bui — Tue, 22 Nov 2016 15:42:20 GMT

@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.

RE: Troubleshooting SoftDevice assertion

Paolo D — Tue, 22 Nov 2016 15:10:16 GMT

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.

RE: Troubleshooting SoftDevice assertion

Hung Bui — Thu, 17 Nov 2016 09:49:49 GMT

@Paolo: have you made sure no flash operation was executed when you are testing ? If you use this example and add the scanner code in would you have the same issue ?

I just tried a quick test here but don't see any issue.

RE: Troubleshooting SoftDevice assertion

Paolo D — Wed, 16 Nov 2016 16:26:23 GMT

Observer and central works, and ESB and central works. The error only occurs when all three are active simultaneously.

I am using the SoftDevice API for scanning.

The central only connects to one peripheral. I am currently using 250ms connection interval and 250ms scan interval.

I am experimenting with the scan window now. It seems to work reliably if the scan window is 20ms, but fails if I increase it to 30ms. When ESB is not active I can use a 50ms scan window without any problem.

RE: Troubleshooting SoftDevice assertion

Hung Bui — Wed, 16 Nov 2016 16:11:42 GMT

PC=0x00011150 points to Radio event management module. If you only do observers and central role, would you have the issue ? (No ESB)

How did you do scanning ? You used the API from softdevice or manually in a timeslot ?

What is the scan window you have ? How many peripheral connect to your central ? What is the interval(s) ?

RE: Troubleshooting SoftDevice assertion

Paolo D — Wed, 16 Nov 2016 14:35:28 GMT

Yes, the error is NRF_FAULT_ID_SD_ASSERT. I am using ESB for bulk data transfer, to transfer as much data as possible in between connection events. I think the radio is always being disabled before the timeslot ends but I will confirm.

If I set the observer's scan interval to be exactly the same as the central's connection interval, then it appears to work reliably. The error only occurs when those intervals are different.

RE: Troubleshooting SoftDevice assertion

Hung Bui — Wed, 16 Nov 2016 10:16:46 GMT

Hi Paolo,

Which faultID have you got ? Did you get NRF_FAULT_ID_SD_ASSERT ? How did you use ESB ? Have you made sure you disabled the radio, timer before the timeslot expires ?