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

[Hung Bui]

Hi Anton, 

Please clarify, you mentioned this sequence "connect-> bond -> disconnect -> connect -> reset -> connect " showed the error. But when exactly you trigger the reset ? On the first connection after bond or on the second ? In the sequence above, it's the second re-connection after bonding. 

Do you see the same problem if you test using ble_app_proximity (adding code to do a reset) ? Which phone did you use for testing ? 

The PM_EVT_LOCAL_DB_CACHE_APPLY_FAILED error happens when we try to apply the system attribute (CCCD value) on a saved connection but it doesn't match with the attribute table. Suspecting corrupted flash operation. We need to find the place where we store the system attribute and try to avoid resetting before it's finished flashing. 

[AntonHellbe]

I do the reset of the nRF52832 inside the PM_EVT_PEER_DATA_UPDATE_SUCCEEDED event with the two following preconditions

p_evt->params.peer_data_update_succeeded.flash_changed
&& p_evt->params.peer_data_update_succeeded.data_id == PM_PEER_DATA_ID_BONDING

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

[AntonHellbe]

Hi,

So If I understand you correctly this would be the sequence you are describing:

Enable Pairing/Bonding (No NUS enabled) -> Connect with Central device -> Bond -> Disconnect and reset nRF5832 into mode with NUS -> Connect with Central -> Re-enable CCCDs -> Disconnect -> Connect.

This above sequence works for me. At first reconnect after bonding and resetting I get PM_EVT_LOCAL_DB_CACHE_APPLY_FAILED. Enabling the CCCDs triggers update of the Peer Data (PM_EVT_PEER_DATA_UPDATE_SUCCEEDED). Disconnecting and reconnecting after enabling the CCCDs now gives the event PM_EVT_LOCAL_DB_CACHE_APPLIED.

[AntonHellbe]

Hi,

Can you take a look at my reply?

Br,
Anton

[Hung Bui]

Yes, it looks OK to me. As mentioned earlier this is not really critical, just the system attribute need to be updated after you change the attribute table, and it's updated on the first connection after the change.