ANT Forum

We are using the S332 v2.0.0 softdevice for a project. In our app, we use the sd_ant_rx_scan_mode_start() to kick off a heavy duty scan consuming the entire radio. However we notice that when periodically scanning (closing the scan channel and restarting the sd_ant_rx_scan_mode_start()), and having a dormant interval between scans of about 5 minutes, on subsequent enables of sd_ant_rx_scan_mode_start() we encounter a softdevice assert which claims it is a memory fault.

Here are the params that we get in the assert handler:
PC = 000293CC, CycleCnt = B884FB54
R0 = 00000001, R1 = 000048C8, R2 = 00000000, R3 = 000293CD

I tried to find some examples of this, but almost all samples permanently enable the rx scan mode and do not enable and disable it like we would like to. Also please note that the softdevice assert occurs after we enable the scan and subsequently call into sd_app_evt_wait().

Here is the usage:
1. configure scan channel for rx_scan (verified this works since we get a boatload of packets as expected)
2. call rx_scan_start(..) and set a 1-2 second timer to close the scan channel
3. on timer: close the scan channel and set a timer for 5 minutes
4. on timer: call rx_scan_start() again with the timer set to 1-2 seconds to close the channel
5. on timer: close the scan channel and set a timer for 5 minutes
6. on timer: call rx_scan_start and the system will hang with a softdevice assert within 500ms

Any advise or pointers are appreciated!

Edit1:
Confirmed that this assertion does NOT occur with the v1.0.2 softdevice. The only changes made to our application was the changes in how we supply the memory buffer for the ANT enable call since that was a little different.

Edit2:
Also confirmed that if we swap the RX scan channel to be a high duty scan channel - the same behavior is observed as soon as the channel is open.      

Thank you for your bug report, we are currently still investigating the issue and I will update the thread once we've identified the source.      

Thank you for looking into this Harrison! I am trying a few experiments and will post any findings here as usual.      

Could there be some lingering timer related issues? Almost seems like 512 seconds have some odd relation to this. Could this be related to RTC since the 24 bit counter there wraps at 512 seconds?      

I'm happy to report that we have identified the issue and are planning to propagate the fix into the next SoftDevice release (which will happen soon after the next SDK release).      

Is there anything we can do app side to work around this fix? Could you share some details on what might be wrong and how we could safely use the heavy duty RX scan and not get this assert?

Pardon me for being a pain, but when do you expect the next softdevice update to get released? Thanks for following up on this!      

You can workaround the issue by forcing an update to high duty search after a few minutes, such as running a master channel or having BLE activity occur.

I'd love to give a timeline if I could, but the update to the SoftDevice is pending changes upstream which we do not have control over ourselves.      

So sounds like if I were to alternate the heavy duty search and the rx scan, this problem would not occur? Is that correct?

Edit:
It seems like immediately after the rx scan, I i do a master channel search - the issue still exists. However, If I alternate the scan after say 5 minutes - things seem to be fixed. I would like to be deterministic about our approach to fix this since I expect this update to make its way into customer devices out on the field.      

5 minutes should be sufficient, the issue can occur after 512 seconds.