Issue with resetting BLE Peripheral device after bonding (PM_EVT_LOCAL_DB_CACHE_APPLY_FAILED)

RE: Issue with resetting BLE Peripheral device after bonding (PM_EVT_LOCAL_DB_CACHE_APPLY_FAILED)

Hung Bui — Thu, 11 Apr 2019 15:29:42 GMT

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.

RE: Issue with resetting BLE Peripheral device after bonding (PM_EVT_LOCAL_DB_CACHE_APPLY_FAILED)

AntonHellbe — Thu, 11 Apr 2019 14:20:37 GMT

Hi,

Can you take a look at my reply?

Br,
Anton

RE: Issue with resetting BLE Peripheral device after bonding (PM_EVT_LOCAL_DB_CACHE_APPLY_FAILED)

AntonHellbe — Wed, 10 Apr 2019 06:35:18 GMT

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.

RE: Issue with resetting BLE Peripheral device after bonding (PM_EVT_LOCAL_DB_CACHE_APPLY_FAILED)

Hung Bui — Tue, 09 Apr 2019 15:12:19 GMT

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.

RE: Issue with resetting BLE Peripheral device after bonding (PM_EVT_LOCAL_DB_CACHE_APPLY_FAILED)

AntonHellbe — Tue, 09 Apr 2019 06:18:44 GMT

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?

RE: Issue with resetting BLE Peripheral device after bonding (PM_EVT_LOCAL_DB_CACHE_APPLY_FAILED)

Hung Bui — Mon, 08 Apr 2019 15:31:56 GMT

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 ?

RE: Issue with resetting BLE Peripheral device after bonding (PM_EVT_LOCAL_DB_CACHE_APPLY_FAILED)

AntonHellbe — Mon, 08 Apr 2019 07:04:08 GMT

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?

RE: Issue with resetting BLE Peripheral device after bonding (PM_EVT_LOCAL_DB_CACHE_APPLY_FAILED)

AntonHellbe — Mon, 08 Apr 2019 06:39:53 GMT

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.

RE: Issue with resetting BLE Peripheral device after bonding (PM_EVT_LOCAL_DB_CACHE_APPLY_FAILED)

AntonHellbe — Mon, 08 Apr 2019 06:34:39 GMT

Hi,

I tried what you suggested, in PM_EVT_PEER_DATA_UPDATE_SUCCEEDED I disconnect the Central device using sd_ble_gap_disconnect and when I receive the disconnect event in the BLE event handler I perform the reset. I still get the PM_EVT_LOCAL_DB_CACHE_APPLY_FAILED.

Why a reset after bonding?
It's quite hard to explain but the short version is that the nRF52832 is a slave device that has different modes, another MCU (master device) controls it and the transitions between different modes is done through resetting the nRF52832 and initializing only the components needed for that mode.

RE: Issue with resetting BLE Peripheral device after bonding (PM_EVT_LOCAL_DB_CACHE_APPLY_FAILED)

Hung Bui — Fri, 05 Apr 2019 15:39:02 GMT

I don't think NUS or QWR has anything to do with flash.

More likely since you comment out NUS, you don't have any CCCD value in your attribute table, so PM_EVT_LOCAL_DB_CACHE_APPLY_FAILED won't appear.

I don't think doing a reset inside PM_EVT_PEER_DATA_UPDATE_SUCCEEDED event handler is the best way. I would suggest to do a disconnect, and when you have Disconnected event, you can trigger a reset in main.c

May I ask why you want to do a reset after a bonding?

RE: Issue with resetting BLE Peripheral device after bonding (PM_EVT_LOCAL_DB_CACHE_APPLY_FAILED)

AntonHellbe — Fri, 05 Apr 2019 12:20:44 GMT

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

RE: Issue with resetting BLE Peripheral device after bonding (PM_EVT_LOCAL_DB_CACHE_APPLY_FAILED)

AntonHellbe — Fri, 05 Apr 2019 12:07:04 GMT

Hi Hung,

I trigger the reset after the first connection after the bond.

I have done some research and I think I have found the cause. I removed the initialization of Nordic UART Service (which also uses the QWR-module. After that I dont receive the error PM_EVT_LOCAL_DB_CACHE_APPLY_FAILED after connecting after a reset.

Can QWR or NUS interfere with writing to the flash?

RE: Issue with resetting BLE Peripheral device after bonding (PM_EVT_LOCAL_DB_CACHE_APPLY_FAILED)

Hung Bui — Fri, 05 Apr 2019 11:27:11 GMT

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.