This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Random BLE Disconnects + PWM

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

  • Is the device crashing & restarting ?

    The App side logs seem to indicate that the diconnection comes from the HW side

    Do you have some HW side logs ?

  • The device doesn't crash nor restart.

    Its keeps advertising but becoms "unconnectable" untill it goes to sleep after we stop attempting to connect.

    This is triggered from BLE_ADV_EVT_IDLE if certain interrupts haven't been received for a while.

    Sleep mode in our case is just disabling peripherals & going to WFE() (no going to POWEROFF or any such operation)

    it seems like BLE_ADV_EVT_IDLE + restarting advertising clears the issue but it's hard to tell for certain what is causing this behavior 

    There is logging functionality on the HW side ofcourse but I haven't been able to reproduce this behavior under test conditions / with debugger connected

  • 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.

  • 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

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

Related