Random BLE Disconnects + PWM

[nikolozka]

Recently our Device started exhibiting random BLE disconnect problems.

It's really hard to debug as not all of our devices are exhibiting this issue and in generally so far I've been unsuccessful in reproducing this bug.

The symptoms are as follows:

• After the app gets connected to the device and for a while everything is normal
• Afterwards there's a random interruption of connection (timing varies but it's definitely not some timeout related as this can take anywhere from sever minutes to hours to manifest)
• The general approach ot this happening is we naturally start an autoconnect procedure this however fails
• the connection gets dropped immediately. The App side logs seem to indicate that the diconnection comes from the HW side::
• sometimes it will never manage to connect and time-out
• sometimes it will diconnect while fetching services

The FW update after which this issue seems to have been introduced among other changed the PWM functionality, namely we switched from using softblink to HW PWM module using nrf_drv_pwm implementation

the PWM is instantiated using the static NRF_DRV_PWM_INSTANCE(0); it has recently caught my attention that this could be using TIMER0 which is reserved for sofdevice use, however I'm unable to get reliable info on whether this way of instantiating it will bind PWM instance to TIMER0

In the meantime I've switched to using NRF_DRV_PWM_INSTANCE(1); but as the issue isn't easy to reproduce I'm having trouble verifying if this is in fact the source of our problems

[Sigurd]

Hi,

the connection gets dropped immediately

Do you know what the disconnect reason is when this happens? Based on your description, I assume it's 8 (BLE_HCI_CONNECTION_TIMEOUT) ?

NRF_DRV_PWM_INSTANCE(0); it has recently caught my attention that this could be using TIMER0

 No, the PWM peripheral is clocked directly from the clock tree, it does not use the TIMER.

[nikolozka]

That is my suspicion as well, Though I haven't been able to observe this with either the debugger or nrf connect or packet sniffer connected. The test devices I'm working this haven;t exhibited this behavior, but It does happen on deployed devices from time to time.
To add some more info we're using:

• NRF_SDH_CLOCK_LF_SRC 0
• NRF_SDH_CLOCK_LF_ACCURACY 1
• NRF_SDH_CLOCK_LF_RC_TEMP_CTIV 2
• NRF_SDH_CLOCK_LF_RC_CTIV 16

The connection parameters are pretty standard too:

• MIN_CONN_INTERVAL MSEC_TO_UNITS(15, UNIT_1_25_MS)
• MAX_CONN_INTERVAL MSEC_TO_UNITS(45, UNIT_1_25_MS)
• SLAVE_LATENCY 3 
• CONN_SUP_TIMEOUT MSEC_TO_UNITS(6000, UNIT_10_MS)

The disconnects happen both on android and IOS, in our production app as well as our internal test app that usesdifferent bluetooth implementation. So there's a high likelyhood of the diconnect originating on the HW side

[Sigurd]

Ok. What nRF5-SDK version, and what SoftDevice variant and version are you using?

[nikolozka]

We're using SDK 15.3 with S132v6.1

[Sigurd]

The FW update after which this issue seems to have been introduced

 Without any logs it is difficult to figure out what the root cause is. If you have the firmware before and after the update, you might want to do a review and look more into what other changes the update did in your firmware, but if it was a very big update with a lot of changes, some nrf_logs that shows the failure might be needed to figure this one out.