CC2642R: Bonds erased after OAD upgrade when address mode is RPA with Public ID

jerome d.

Part Number: CC2642R

Tool/software:

Dear All
We are facing an issue when using RPA with Public ID address mode in our app.
If using Public address mode, this issue does NOT occur.

We are developing MIDI over BLE device, multi role, until now we were using Public address, but we found connecting multiple devices in Windows does not work if using Public address (previous device has to be removed from the list even if its BLE address is different than the new one). This windows issue is solved when using RPA with Public ID.

The problem we are facing when using RPA with public ID in the app is that the bonds are getting erased (or corrupted) after an OAD upgrade.
We are using latest libraries 8.30, OAD on chip.
NVS is defined at 0x34000 for both the persistant app and the app.
OAD Persistant app uses Public address mode, without security, so no bonding occurs while entering the persistant app.

We do not understand why the bonds are erased or corrupted after the OAD upgrade ?
I found in the document enhanced OAD advanced :

Task 2 – Add On-Chip OAD to Multi Role

In BLE → General Configuration, change the Address Mode to Public Address.

But in our app we must keep RPA with Public ID to solve the Windows issue described above.
Again, we do not face this issue when using Public address mode, the issue occurs only when using RPA with public ID.

Thanks for any tips you can provide.
Jerome

4 months ago

0 jerome d. 4 months ago

Expert 1325 points

To illustrate this issue, here is a dump of the NVS 0x34000 before and after the OAD upgrade.
I upgraded with the same firmware.

Before OAD, the NVS section is as follow : We can see our settings (stored in NVS) plus the bonding after one pairing to one central.

After OAD with the same firmware, no more bond added, we can see the existing bonds are corrupted :

Using an hex file comparator :

Thanks for any tip you may provide.

0 Tarek D 4 months ago in reply to jerome d.

TI__Expert 4200 points

Hello,

Thank you for reaching out! We will take a look at your issue and get back to you ASAP!

Best Regards,
Tarek

0 Tarek D 4 months ago in reply to jerome d.

TI__Expert 4200 points

Hello Jerome,

I apologize for the delay! This is a very good question. After the firmware update, device initialization happens, which causes the generation of a new IRK (identity resolving key), which will invalidate the data inside NV, causing it to be overwritten. Therefore, using public address is required in this situation.

Best Regards,

Tarek

0 jerome d. 4 months ago in reply to Tarek D

Expert 1325 points

Hi Tarek
Does this mean any BLE device using Random address with public Id will loose bonding after OAD ?
I'm surprised to read this as OAD is not supposed to affect that part of the NVS.
Any workaround ?

I'm going to random address with public ID to solve another issue with windows that occur when using Public address.
If using public address with windows, I cannot connect a second BLE device without removing the previous connected.
I read somewhere in this forum that unchecking IRK keys distribution for both central and peripheral could solve this window issue, but it still does not work and allow me to connect 2 BLE devices to windows.

So if you have a solution that solves this windows issue, I'm ok to go back to public address mode.
Thanks

0 Tarek D 4 months ago in reply to jerome d.

TI__Expert 4200 points

Hello Jerome,

OAD does not affect NV, however when the device initializes itself after a firmware update, device_init() is called which causes the NV region that contains the LTK to be erased. This only happens with RPA and not public address. One way to possibly bypass this issue, is to attempt to extract the IRk using gapBondMgrImportBond() function, and save it in another section in NV. For more info this API and it's functionality:

https://dev.ti.com/tirex/content/simplelink_lowpower_f3_sdk_8_40_02_01/docs/ble5stack/ble_user_guide/html/ble-stack-5.x/gapbondmngr-cc23xx.html#gapbondmgr-examples-for-manipulating-bonding

https://dev.ti.com/tirex/content/simplelink_lowpower_f3_sdk_8_40_00_61/docs/ble5stack/ble_user_guide/doxygen/ble/html/group___g_a_p_bond_mgr.html#gab36e5dd569942e6260517c73ea7042cf

As for the windows issue, if you would like to use public address rather than RPA, I would recommend opening a new thread on E2E to discuss it.

I hope this helps!

Best Regards,

Tarek

Bluetooth®︎

Bluetooth forum

CC2642R: Bonds erased after OAD upgrade when address mode is RPA with Public ID

Task 2 – Add On-Chip OAD to Multi Role