Problem with sd_ble_gap_scan_stop

Question

I am experiencing a strange problem with stopping a scan. I am using the mesh from github.com/.../nRF51-ble-bcast-mesh together with interval scanning, meaning start scanning, wait 2 sec, stop scanning, pause 2 sec, start scanning, etc.
At one point, the program simply stops in the call to sd_ble_gap_scan_stop, without error or hardfault or anything. The failure time is not the same, so I can't really reproduce the error. But I am reasonably sure that it has to do with the combination of mesh and scanning, because if I disable the mesh, the error doesn't happen. Since I have no way of checking what happens in the sd_ble_gap_scan_stop I am at a loss. Can somebody tell me why the function would deadlock without any error or timeout? 
 I am using: Softdevice s132 v2.0, nrf5 SDK 11.0.0, and a PCA10040 board

Trond Einar Snekvik · Accepted Answer

Hi, nRF52 support for the mesh is still in development, but we're finishing up on them now, and hope to release an update sometime next week. 
 I believe this error is caused by the timeslot not ending correctly. Contrary to the S110 and S130, the S132v2 doesn't clear the state of the HW timers before starting and after ending the timeslot, and this can often cause issues. 
 Try adding this piece of code to the end of the timeslot_end() function in timeslot.c : 
 #ifdef NRF52
NRF_TIMER0->TASKS_STOP = 0;
NRF_TIMER0->TASKS_SHUTDOWN = 1;
for (uint32_t i = 0; i < 6; i++)
{
 NRF_TIMER0->EVENTS_COMPARE[i] = 0;
 NRF_TIMER0->CC[i] = 0;
}
NRF_TIMER0->INTENCLR = 0xFFFFFFFF;
NVIC_ClearPendingIRQ(TIMER0_IRQn);
#endif
 
 It'll reset our HW timer before leaving the timeslot, to prevent the Softdevice from tripping up. 
 In addition, add these lines to the start of the for-loop in timer_on_ts_begin() , to clear the HW timer at the beginning of our timeslot: 
 NRF_TIMER0->CC[i] = 0;
 NRF_TIMER0->EVENTS_COMPARE[i] = 0;
 (void) NRF_TIMER0->EVENTS_COMPARE[i];
 
 This should be the first thing to happen in the for loop. 
 These changes are on their way into the official implementation, but we're still doing some polishing :)

Problem with sd_ble_gap_scan_stop

Top Replies