Issue with resetting BLE Peripheral device after bonding (PM_EVT_LOCAL_DB_CACHE_APPLY_FAILED)

[AntonHellbe]

Hi,

I have an issue with bonding and resetting my BLE Peripheral device (NRF52832) after the bonding process is complete. Currently I press a button that initiates the bonding procedure, after that the central device (e.g my smartphone) bonds with the the peripheral device. When the bonding is complete I tell the BLE Peripheral to reset itself and update the whitelist and advertise using the whitelist by fetching the bonding information from flash. That part works fine, however when I connect with the central device after the reset i get the error: PM_EVT_LOCAL_DB_CACHE_APPLY_FAILED event inside the peer manager event handler. The central device can still connect though.

I dont get the error PM_EVT_LOCAL_DB_CACHE_APPLY_FAILED if I: connect -> bond -> reconnect (without restart of BLE Peripheral). But if I do connect-> bond -> disconnect -> connect -> reset -> connect the error shows up again.

I've tried using timers to delay the reset since writing to flash is done asynchronously (thinking maybe the reset was done too quickly) but it did not help.

Quick Edit:

Im using SDK V15.0

Softdevice: S132 6.0

Hardware: nRF52832

[AntonHellbe]

Another observation is that It does not seem to matter if I wait a long time before doing the reset (I.e the time between bonding and resetting the device is not the issue?) Because I've tried doing it with doing a manual reset and waiting >10s after bonding and the issue still persist.

[AntonHellbe]

Hi Hung,

I have an idea why it might I'm getting PM_EVT_LOCAL_DB_CACHE_APPLY_FAILED. Perhaps you can confirm or deny it.

As I have explained in one of my previous comments the nRF52832 is a slave device that has different modes. The mode when the nRF5832 accepts pairing/bonding does not have NUS/QWR enabled. However the mode that it gets put in after pairing/bonding does have NUS/QWR enabled.

So my theory about this issue is that when the nRF52832 resets after pairing/bonding and we initialize NUS which changes the attribute table has changed (because we have added NUS) and therefor Peer Manager is unable to apply the Local DB cache. What do you think?

[Hung Bui]

I think your theory is correct. When you change the attribute table, and then you want to apply the system attribute from the old attribute table, the softdevice will complain. 

I haven't looked into how to properly solve this , but as far as I know this is just a warning , so it's not an assert if softdevice return PM_EVT_LOCAL_DB_CACHE_APPLY_FAILED. It's just some CCCD can't be restored. And it will be stored correctly next time you reconnect (if you don't continue to change the attribute table again).

Where did you find the assertion when you receive this PM_EVT_LOCAL_DB_CACHE_APPLY_FAILED ? 

[AntonHellbe]

Hi,

I have not found any assertion regarding to this, I just noticed this by having a log statement inside some of the events in the PM event handler.

One thing that I noticed that I found strange is that I dont receive the error (PM_EVT_LOCAL_DB_CACHE_APPLY_FAILED) If I have NUS enabled during pairing, then resetting into a mode that does not have NUS enabled. So it seems like removing CCCD:s after pairing/bonding is OK but adding CCCD:s triggers PM_EVT_LOCAL_DB_CACHE_APPLY_FAILED.

So where do we land on this issue? Can it be just ignored since it's just a warning, or can it have any consequences for the application?

[Hung Bui]

I'm not so sure, but if you add the NUS at the bottom of the attribute table shouldn't cause an issue. Anyway I don't think this would be a serious bug. If you can check and verify that you have your CCCDs re-enabled after you disconnect and reconnect (not the first time) then it's fine.