• State
  • Replies 7 replies
  • Subscribers 50 subscribers
  • Views 76 views
  • Users 0 members are here
Support feedback
Options
Options
Related

CC2642R-Q1:SDK upgraded from 0710 to 0741 cannot recognize NV binding information

xd z
Prodigy 40 points
Part Number: CC2642R-Q1

Tool/software:

Hello, I am in the following project. C:\ti\simplelink_cc13xx_cc26xx_sdk_7_10_01_24\examples\rtos\CC26X2R1_LAUNCHXL\ble5stack\simple_peripheral。 We have developed our application. We will complete the pairing of jutwork with the mobile app. The NVS configuration of our program is as follows:

Then my new version was developed in the following project: C:\ti\simplelink_cc13xx_cc26xx_sdk_7_41_00_17\examples\rtos\CC26X2R1_LAUNCHXL\ble5stack\simple_peripheral
The NVS area configuration is as follows:

After completing the pairing and binding under the 0710 SDK version, I upgraded to the 0741 SDK version without erasing and downloading NVS and ccfg. However, the encrypted connection could not be completed, and my phone would prompt that the car pairing information was lost.
The following image is a comparison of the NVS readings before and after I upgraded the 0741 SDK version of the program
On the left is the NVS area before upgrading the 0741 SDK, and on the right is the NVS area after upgrading the 0741 SDK

My understanding of the above question is:
The binding information for the NVS region of the same routine in SDK 0710 is not recognized for version 0741.
In addition, I have verified that the upgrade of the same SDK version can be recognized.
Please help confirm the issue and its cause, as well as whether there is a solution that can enable the 0741 version SDK to recognize the NVS data of the 0710 version SDK.

  • 0
    TI__Intellectual 2610 points

    Hi,

    I run test in steps:

    1. Flash simple_peripheral in SDK 7.10.01.24, bond with phone, read out NV starting from 0x52000

    2. Flash simple_peripheral in SDK 7.41.00.17, then read NV starting from 0x52000

    Compare two NV, they are the same. 

    Can you make sure you observe the same?

    BR.

  • 0 in reply to Barbara Wu
    Prodigy 40 points

    The effect I tested here is that the NV read from 52000 is different. The comparison result is shown in the picture I posted earlier.

  • 0 in reply to xd z
    Prodigy 40 points

    You can see that the comparison of NV I provided earlier includes an address of 52000.

  • 0 in reply to Barbara Wu
    Prodigy 40 points

    HI

    １、Today, with the assistance of your engineers, we have identified the cause of the problem. It's because I set the Address Mode in the General Configuration Configuration General BLE Settings to Public Address. In the SDK of 0741, the Address Mode is set to Random Static Address. Due to this change, your SDK has removed the binding information.

    ２、I want to confirm that if the MAC address type changes, your SDK will need to delete the binding information. Is this necessary? Is there a Bluetooth core specification that requires this to be done? If there is such a requirement, please provide the source of this requirement. If it's not required by the Bluetooth Core Specification or the Bluetooth Technology Alliance, can you change this practice? Is it possible not to delete the binding information even when the MAC address type changes?

    ３、I saw the following description in your official link:

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

    My maximum binding quantity in SDK 0710 is 10, and in SDK 0741 it is 30. According to the instructions on your official website, if I want to upgrade, I must
    Wipe off NV.
    Now that the MAC address type has changed, your SDK has deleted the binding information. In this case, do I still need to do a complete erasure of NV?

  • 0 in reply to xd z
    TI__Intellectual 2610 points

    Hi, 

    If Address type changed, the device will be identified as a different device. So old bond information does not work for "new" device, which is a normal behavior.

    If increase the number of bonding records,  a full NV erase is "must" operation.

    BR. 

  • 0 in reply to Barbara Wu
    Prodigy 40 points

    hi 

    Your Answer   " If increase the number of bonding records, a full NV erase is "must" operation."

    What is the reason for having to do this? Can you please explain to me, and what problems may exist if all NV erasures are not done?

  • 0 in reply to xd z
    TI__Intellectual 2610 points

    Because each bonding information will need to write into NV. Changing the GAP_BONDINGS_MAX means different amount of NV entries in maximum. The old information stored in NV may have conflicts to the information need to store under newer configuration. Which will cause abnormal behavior during encryption process.