Prevent BondKey storage to NVRam

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

Hi,

In my application, I have a use case where I have multiple BLE peripherals (about 10 devices) which are rotated with the central.  A bond is made with each one of them, but the number of bond keys that can be stored is set to 6.  So after the 6 devices, I can no longer bond.   At this point, I need to manually delete the bond key from the central and a new bond is created each time.

So my question is if it is possible to prevent a write to the NVRam for the bond keys and instead cache it?  Or perhaps some callback which I can feed in the bond key from the connected host?  I'm worried about the eventual wear on the external NVRAM.

I am currently using SDK 2.2.1 and using the BCM20737 for both peripheral and central.  Keys are only stored at the central side.

0 Likes
16 Replies
MiTo_1583836
Level 5
Level 5
50 likes received 25 likes received 10 likes received

Ave you looked at a increasing the value from 6 to 10? Also what is the frequency of deleting and adding a new bond?

0 Likes
Anonymous
Not applicable

Hi 79rpm,

I'm not looking to increase the number of bonds, but I want to know if there is a way to store the bond information somewhere else like RAM.  In a normal use case, the number of bonds won't exceed 6.  However, we have a few USE CASEs where there can be 20 devices with their connections rotated periodically every 5 mins.

My worry is that this scenario will wear out the eeprom.  I'm hoping there is some hidden api or trick that would allow me to bypass the eeprom update or allow me to intercept this and store the bond information to the connect host of this BRCM central device.

0 Likes

Hi nchan,


Have you find a solution at your problem? I have the same application issue and I don't know if the use of an external EEPROM could resolve this.

0 Likes

Hello,

You could store the bonding information in RAM and go back to EEPROM when the device is low on battery or switching off.

0 Likes
Anonymous
Not applicable

Hi 79rpm,

Is there an API to selects the storage of the bonding information to RAM or EEPROM?  So far it just seems to automatically store to NVRAM.  Insight to this would be much appreciated!

-Howard

0 Likes

Well I look at the struct called HOSTINFO in hello_sensor.c for example. Instead of calling bleprofile_WriteNVRAM() with the bonding information I would create a specific function that store the data in RAM (array) and use the HOSTINFO struct as a parameter. You can still use bleprofile_WriteNVRAM() if there is a need for persistency across reboots.

0 Likes
Anonymous
Not applicable

Hi 79rpm,

Thanks for looking into it.  So I looked at the hello_sensor.c and the event callback hello_sensor_smp_bond_result(...) which is saving some application data to the NVRAM_ID_HOST_LIST.  But I don't see how that is related to the internal bond key storage.  If you remove this code, the bond key will still be stored by the BLE stack.

If you refer to https://community.broadcom.com/message/9501?et=watches.email.thread#9501 , there is a reference to the file stacknvram.h which references to STACKNVRAM_BOND_INDEX.  Looking at the dump of the NVRAM, this contains the table of bonded bd address with a link to a NVRAMID index.

// ID 2 - Bond Index

0200 : 82 28 af 0c 01 10 ef be ad de 00 00 27 7f 17 72

       ID SZ CS??? ^--BDADDR-------^ ^ID0^ ^--BDADDR--

0210 : 01 a8 00 01 25 7f 17 72 01 a8 00 02 00 00 00 00

       ----^ ^ID1^ ^--BDADDR-------^ ^ID2^ ^--BDADDR--

0220 : 00 00 00 00 00 00 00 00 00 00 00 00 c0 5f 62 5b

       ----^ ^ID3^ ^--BDADDR-------^ ^ID4^ ^--JUNK----

0230 : 17 67 17 c3 c0 6a 83 71 e8 5b 37 34 00 00 00 00

       ----------------------------------------------^

which is used to index to the actual bond information:

// ID 3 - Bond for 1001

0180 : 83 78 1b 43 01 10 ef be ad de 00 00 00 90 00 00

       ID SZ CS??? ^--BDADDR-------^ ^EDIV

0190 : 00 04 20 00 01 02 00 00 b6 9f 68 16 ef 64 60 ae

       ^--RAND---------------^ ^--IRK-----------------

01a0 : db 93 fd 03 db 93 fd 05 69 a1 4d cc 91 6c 95 de

       ----------------------^ ^--SIGNING-------------

01b0 : 04 f0 95 bf 9e 8a e9 1d 00 00 00 00 3e 35 18 65

       ----------------------^             ^--LTK-----

01c0 : 6a 28 ca 9c c7 a5 19 3d ad 05 24 4a 0c d8 40 d4

       ----------------------------------^

So I'm looking a way to prevent the above from happening, and just store in RAM. 

Also in the file Wiced-Smart/tier2/brcm/libraries/lib/readme, I found this:

------------------------------------------------------------------

smp_multi_key_storage

------------------------------------------------------------------

Allows storage of more than 5 hosts by overwriting the oldest.

This is a required patch if pairing with more than one host is required.

which I have included into the makefile, but at the moment it doesn't seem to do what it describes.  Not sure if you have tried using this or not?

0 Likes

I am sorry I had to re-read the initial question and saw this comment about the bond keys.

I may try to write a wrapper for the NVRAM access API and provide the definition of the new function during the link of the application. The wrapper has to be smart enough to differentiate the bond key storage (going to RAM) vs another operation. The only concern I have is not being able to access the initial NVRAM API after that. I need to give it a shot and confirm.

Anonymous
Not applicable

That sounds great, keep us posted on the progress of that

0 Likes

More thinking on this. We don't have the source of the BT stack and no access to the source code of the NVRAM API. So I don't believe we can introduce a wrapper at this point. The many calls to NVRAM API in the BT stack are hidden to us. Without the help from Broadcom I don't believe this is possible.

0 Likes
Anonymous
Not applicable

I agree with your assessment.  Hopefully someone from Broadcom can chime in on this

0 Likes

I asked jamesle1​ to check with the developers to determine if an alternate storage location is possible through the SDK/API that is supported in the broad market.

Anonymous
Not applicable

Thanks mwf_mmfae!

BTW, do you know if the smp_multi_key_storage library in Wiced-Smart/tier2/brcm/libraries/lib/ is working and what do you need to do to invoke it?  Currently I have included it into my makefile, but it seems like it is not overwriting the oldest.  Do you know if there is something additional that needs to be performed?

------------------------------------------------------------------

smp_multi_key_storage

------------------------------------------------------------------

Allows storage of more than 5 hosts by overwriting the oldest.

This is a required patch if pairing with more than one host is required.

0 Likes
Anonymous
Not applicable

Hello.

I looked into this problem, and I'm sorry but our BLE stack will always write to NVRAM when a bond is created. There's no way around it as long as you are using our stack.

As for using smp_multi_key patch, there's shouldn't be anything else that you would have to do other than adding the patch to the makefile.

I experienced the same thing where only the first key(BDADDR) at index 0 gets updated even with the patch.

Not sure what the problem is. Our developers are pretty busy these days, but I'll try to ask them what the problem may be sometime next week.

If having the most updated list is important, I suggest you to just save your own list in the RAM and load the data to NVRAM in the application section(0x10 to 0x6F) whenever you have to turn the device off (something like what 79rpm suggested), and just ignore what the stack is doing.

Thank you.

James

0 Likes
Anonymous
Not applicable

jamesle1

Thanks for the reply.  One thing I noticed about the smp_multi_key_patch is that there are times where it will no longer allow bonding of any new devices unless I delete all bonds (via lesmpkeys_removeAllBondInfo())  and even that only works some of the time.

But I would appreciate if you can ask about the this issue to the developers.

-Howard

0 Likes

Hello hchan

Are you still seeing issues with the smp_multi_key_patch? As long as you build clean and then add the patch with

APP_PATCHES_AND_LIBS += smp_multi_key_storage.a

in the makefile you should see the bondings after the max amount stored in idx0, idx1, idx2, and so on.

If you are seeing problems where it will no longer allow bonding, you may have run out of space for the bonding table if you are storing other information in the NVRAM as well. You can change the EEPROM memory map to allocate more space into the key storing area and adjust the .DS area accordingly. For instance, if you want to increase the area from 1K to 2K, change the following in the file <SDK>//Platforms/BCM920737TAG_Q32/20737_EEPROM.btp.

1. DLConfigVSLength to 2048

2. ConfigDSLocation to 2432

You can also change the maximum number of devices in the bonding table with adding

extern UINT8 lesmpkeys_maxBondedDevices;

lesmpkeys_maxBondedDevices = 6;

in the create function. Make sure you have enough space in the VS area before increasing the max number of bondings though.

If you want to OTA upgrade after this change, you will have to update the default layout for EEPROM or Serial Flash in ws_upgrade.c and change the corresponding values in nv_loc_len[].

Let us know if this works for you.

Thanks,

Jaeyoung

0 Likes