BLE stopped advertising and app timers slowed significantly

Hi, 

Im currently working with a custom PCB using the nRF52832 and soft device s132 with v5.1.0.

Sometimes the BLE stops advertising and becomes undetectable after a connection (and subsequent timed out disconnection) with a Mobile device. This happens very rarely, but once it is in this state, the only way to get the BLE advertising again is through a hard reset.

We have mechanisms in place for ensuring constant advertisement in various scenarios such as timed out connection, missing a GAP Disconnection EVT, interval checks for advertising state (local state variable), etc.

The BLE advertisement is always set at an interval of 700 ms, 0 slow advertisement timeout, in an unbonded connectable advertisement mode.

Most notably however is that the app timers also seem to be running extremely slowly at about 8 seconds passing on device compared to 5 minutes real time. Typically these app timers are running every real time second, but in this state they run significantly slower for some reason.

I’m wondering:

  1. If there is a deterministic way to detect this state in order to build diagnostics or error handlers to restart the advertisement properly?
  2. Are there any known issues with soft device s132 v5.1.0 with respect to BLE advertisement and/or timers that may explain this scenario?
  3. If/how this scenario relates to the BLE stack in general and any suggestions for prevention?

Any input is appreciated, thanks!

Parents
  • All the known issues that were discovered after releasing S132v5.1.0 can be found if you look at bux fixes and known issues for all the releases in the release notes.s132_nrf52_7.2.0_release-notes-update-2.pdf

    Based on your description it is hard for me to narrow down what the problem could be. Some logs or the context where it happens or the context into which the CPU goes after this happens will be helpful. It would be also good to know if there were any fault exceptions happened or if there was any spikes in the power source. We can take it from there with the information you provide. 

    Also please provide which chip version you are using (lazer markings on the nRF chip)

Reply
  • All the known issues that were discovered after releasing S132v5.1.0 can be found if you look at bux fixes and known issues for all the releases in the release notes.s132_nrf52_7.2.0_release-notes-update-2.pdf

    Based on your description it is hard for me to narrow down what the problem could be. Some logs or the context where it happens or the context into which the CPU goes after this happens will be helpful. It would be also good to know if there were any fault exceptions happened or if there was any spikes in the power source. We can take it from there with the information you provide. 

    Also please provide which chip version you are using (lazer markings on the nRF chip)

Children
No Data
Related