NRF52840 Wont Respond to LL_FEATURE_REQ without Clearing Android Bluetooth Storage

Hi Everyone,

I'm having an issues connecting a Lenovo TB-X606F tablet (running android 10) to an nRF52840 (running SDK 15.3). The issue start randomly but once I begin having issue they happen repeatedly for each subsequent connection attempt. I try power cycling the Nordic, restarting my app, and restarting the tablet but the only way I can reliably resolve the issue is to go into the android system apps of the tablet and clear the storage for the system Bluetooth app. 

This all lead me to believe that this is an issue with the tablet. However when I look at protocol analyzer traces I see the tablet sending a CONNECT_IND packet followed by several retries of the same CONNECT_IND packet sent from the tablet and the Nordic completely ignoring said packet. 

Connect_07_Pass.xlsx : Successful connection CONNECT_IND packet #3676 (line 143)

Connect_01_Fail.xlsx : Failed connection first CONNECT_IND packet #722 (line 18). File contains many connection attempts

I'm at a bit of a loss as to how to proceed since the resolution would suggest the tablet is at fault however the protocol analyzer seems to indicate the device is misbehaving. 

Thanks!

 

 

edit: added capture after adding ble_advertising_restart_without_whitelist. Noticed lost data in FDS possible flash corruption. 

  • Can you share the ellisys sniffer log file?

    It's common that some connection request packets are lost due to for instance noise or interference, however if a lot (or all) connection packet requests are ignored in a row, this indicate that the peripheral are whitelisting the advertisment, and that the central device is not in the whitelist. Are you sure the peripheral have not by accident paired with a different in the meantime and/or have you tried restart advertisment without whitelist (there is a api for it) to check if that have an impact on the issue?

    Kenneth

  • Thank you for your reply. You'll find the full Ellisys captures now attached to my original post. It doesn't seem likely that the device is connecting to another central since this is being replicated several different dev environments  where we typically use a single central device. I'm not terribly familiar with whitelisting but wouldn't this be cleared by restarting the device? Also why would clearing the system BLE storage on the central resolve this issue if this was the case?

  • I am pretty sure the the problem is occuring due to an issue with the peripheral, and that the peripheral have enabled whitelist, and likely the whitelist is with the wrong and/or missing peer that it want to allow to connect. As a simple test you can try to call ble_advertising_restart_without_whitelist() on the peripheral side when advertising, this will disable whitelist while advertising, and I suspect in such case that the central will be allowed to connect.

    In general I suggest to take a look at the ble hid keyboard or mouse example for reference, search for whitelist in main.c.

    Best regards,
    Kenneth

  • Ok thank you. I will try this out. Unfortunately it will be a week or so before I will be able to use the sniffer again but I'll let you know what I find.   

  • Hi Kenneth, 

    I added a ble_advertising_restart_without_whitelist as you suggested. It didn't seem to resolve the issue. I did notice that I'm loosing application data from the FDS while power cycling the nRF52840 in an attempt to induce the issue. The sniffer logs are a bit different (02_puck_57f7_fail_noBLELED.btt) but the external behavior of the system is consistent with the behavior I was seeing before. Do you think FDS corruption could be the cause of the behavior originally observed? 

    Thanks!

Related