• State Not Answered
  • Replies 6 replies
  • Subscribers 25 subscribers
  • Views 258 views
  • Users 0 members are here
Attachments (5) Download All
Nordic Case Info
  • Case ID: 288697
Options

NRF52840 Wont Respond to LL_FEATURE_REQ without Clearing Android Bluetooth Storage

user115923

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. 

Parents
  • 0

    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

  • 0 in reply to user2111

    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!

  • 0 in reply to user115923

    Difficult to say, this log doesn't show any connection request packets from the peer, which is very odd even if FDS is corrupted. Corruption in FDS can for instance impact encryption fail, but I don't see why it would affect a peer that have established a bond previously not to try to connect. Maybe the peer did connect at some time, then found encryption failed, and thereby have decided not to connect again. I think this is a different problem from your origianl problem.

    Kenneth

Reply
  • 0 in reply to user115923

    Difficult to say, this log doesn't show any connection request packets from the peer, which is very odd even if FDS is corrupted. Corruption in FDS can for instance impact encryption fail, but I don't see why it would affect a peer that have established a bond previously not to try to connect. Maybe the peer did connect at some time, then found encryption failed, and thereby have decided not to connect again. I think this is a different problem from your origianl problem.

    Kenneth

Children
No Data
Related
Terms of service