Hi,
We're working on the connection params negotiation. Therefore we need a timer to go off 2 seconds after connecting to send a conn params change request.
Most of the time this works as expected. We toggle some pins at timer start and in the handler and we see that the distance is exact 2 seconds, yet sometimes it can take 16 seconds or even 55 seconds for the handler to be called. During this time the board consumes about 970 mA. Connection seems to be maintained (preferred connection interval between 175 and 195 ms with a preferred slave latency of 2).
So now we have extracted the issue. I've made a project with just enough code to start the BLE stack and start advertising. I can reproduce the issue with 2 app_timers. One REPEATED timer, one SINGLE_SHOT timer. I'm also using TIMER2 to show the delay.
The repeated timer is started on boot, and triggers every 15 seconds. When I receive the CONNECTED event I stop the repeating timer and start a single shot timer at 3 seconds. I also start TIMER2 at 2 seconds. I then expect my measurements to look like this:
Which it does, most of the time, if I use an Android device which previously has connected to the device. It doesn't even matter if the device has rebooted/flashed in the meantime.
When disabling Bluetooth in Android and enabling again results in the single shot timer to be significantly delayed. So the measurements look like this:
The red line is TIMER2, the blue line is the single shot app_timer.
This happens primarily (9 out of 10) when the Android device has disabled and enabled Bluetooth, and happens sometimes (1 out of 10) when the Android device has previously connected and not disabled Bluetooth in between connections. In the last scenario the delay is typically smaller (10 seconds or so).
I've pushed all code to this github project: github.com/.../nrf51-ble-dongle
Why is the app_timer behaving like this?
