1 2 Previous Next 16 Replies Latest reply on May 24, 2016 6:46 AM by JaeyoungY_71

    Prevent BondKey storage to NVRam

      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.

        • 1. Re: Prevent BondKey storage to NVRam
          MiTo_1583836

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

          • 2. Re: Prevent BondKey storage to NVRam

            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.

            • 3. Re: Prevent BondKey storage to NVRam
              Juar_2150386

              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.

              • 4. Re: Prevent BondKey storage to NVRam
                MiTo_1583836

                Hello,

                 

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

                • 5. Re: Prevent BondKey storage to NVRam

                  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

                  • 6. Re: Prevent BondKey storage to NVRam
                    MiTo_1583836

                    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.

                    • 7. Re: Prevent BondKey storage to NVRam

                      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?

                      • 8. Re: Prevent BondKey storage to NVRam
                        MiTo_1583836

                        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.

                        • 9. Re: Prevent BondKey storage to NVRam

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

                          • 10. Re: Prevent BondKey storage to NVRam
                            MiTo_1583836

                            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.

                            • 11. Re: Prevent BondKey storage to NVRam

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

                              • 12. Re: Prevent BondKey storage to NVRam
                                MichaelF_56

                                I asked userc_19497 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.

                                • 13. Re: Prevent BondKey storage to NVRam

                                  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.

                                  • 14. Re: Prevent BondKey storage to NVRam

                                    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

                                    1 2 Previous Next