• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 17 subscribers
  • Views 351 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2652R: NVS used in the BLE5-Stack

Cherry Zhou
Mastermind 22235 points
Part Number: CC2652R
Other Parts Discussed in Thread: SYSCONFIG

Hi team,

Here's some issue from the customer may need your help:

The example project is C:\ti\simplelink_cc13x2_26x2_sdk_5_20_00_52\examples\rtos\CC26X2R1_LAUNCHXL\ble5stack\simple_pe Ripheral_oad_offchip. The CLang compiler is used, and the IDE is CCS.

Simple_peripheral_oad_onchip.syscfg -> TI DRIVERS -> NVS has two NVS regions: CONFIG_NVSINTERNAL and CONFIG_NVSINTERNAL. Where Region Type of CONFIG_NVSINTERNAL1 selects Pointer, base address is 0x0, and region size is 0x34000, as shown in the following figure:

Q1: There is no CONFIG_NVSINTERNAL1 region in the simple_peripheral project, only CONFIG_NVSINTERNAL region.

What is the role of CONFIG_NVSINTERNAL1 in OAD Engineering? The base address is 0x0 and the area size is 0x34000, which is the firmware area for the entire application.

Why call nvs_read and nvs_write, dose is even need to modify the firmware's own code? The Region Type for CONFIG_NVSINTERNAL is Generated, the base address is 0x34000, and the region size is 0x4000, as shown in the following figure:

The compiled Memory Allocation is shown in the following figure, the entire Flash size is 136K, and the region defined by CONFIG_NVSINTERNAL is assigned to the .TI.bound.flashBuf0 section in FLASH. The size is 16384 (that is, 0x4000):

Select Region Type for CONFIG_NVSINTERNAL to Pointer, base address is 0x34000, and area size is 0x4000, as shown in the following figure:

The compiled Memory Allocation is as shown in the following figure, and the entire Flash size is 120K (16384 (0x4000) when Region Type is Generated). Cannot find zone assignment defined by CONFIG_NVSINTERNAL：

Q2: As prompted in sysconfig for the Region Type field, Generated — automatically generates the flash internal region; Pointer- assigns the region to the address specified by Region Base.

Is the pairing bind information for BLE saved in the area defined by CONFIG_NVSINTERNAL?

Is the region defined by CONFIG_NVSINTERNAL calling the osal_snv_read and osal_snv_write operations? Why is this area not present in the final firmware in the way that Pointer is configured? But test BLE pairing, binding, and osal_snv_read/write are normal.

Could you help check this case? Thanks.

Best Regards,

Cherry

  • 0
    TI__Mastermind 27820 points

    Hi Cherry,

    It seems you have a few questions here, so I'll try to answer each one individually:

    Cherry Zhou said:
    What is the role of CONFIG_NVSINTERNAL1 in OAD Engineering?

    This is to create room for the OAD image's NVS.

    Cherry Zhou said:

    Is the pairing bind information for BLE saved in the area defined by CONFIG_NVSINTERNAL?

    No, but the bonding information is stored in NV memory.

    Cherry Zhou said:
    Is the region defined by CONFIG_NVSINTERNAL calling the osal_snv_read and osal_snv_write operations?

    This would not make sense to me, NVS is used to store data, not instructions, so I think it's unlikely you're storing instructions there.

    Cherry Zhou said:
    Why is this area not present in the final firmware in the way that Pointer is configured?

    I don't know why it isn't shown in the diagram you've posted, but I'm asking internally and an expert will comment.

    Best,

    Nate

  • 0 in reply to Nathan Block
    TI__Mastermind 22235 points

    Hi Nate,

    Thanks for your support!

    Nathan Block said:
    No, but the bonding information is stored in NV memory.

    This CONFIG_NVSINTERNAL defined area is the NV memory, following the instructions for placing the OSAL SNV in the ble5-Stack User Wizard. Read and write with NVS_read and NVS_write, which is the upper layer of the osal_snv_read and osal_snv_write functions.

    Nathan Block said:
    This would not make sense to me, NVS is used to store data, not instructions, so I think it's unlikely you're storing instructions there.

    Maybe there's a misunderstanding. Let me clarify: the customer don't mean to store data, they would like to know if the region defined by CONFIG_NVSINTERNAL is where the osal_snv_read and osal_snv_write operations are called.

    Nathan Block said:
    I don't know why it isn't shown in the diagram you've posted, but I'm asking internally and an expert will comment.

    Thanks again, expect your response.

    Best Regards,

    Cherry

  • 0 in reply to Cherry Zhou
    TI__Mastermind 25810 points

    Hey Cherry,

    Taking a look at the NVS regions defined along with the .cmd linker files in both the on chip OAD and persistent app projects, I was able to verify that the CONFIG_NVSINTERNAL (i.e. region 0x00034000-0x00038000) are the last 2 pages of NV. You are correct, when the application uses osal_snv_write() for example, it will write to that space. A quick test would be to perform a quick write (perhaps use a customer NV item) and read back this information in SmartRF Flash Programmer to find the written data and where it is written to.

    When changing from "Generated" to "Pointer", you'll find that SysConfig no longer reserves the NVS space using a statically defined buffer (i.e. FlashBuf0). For this reason, you do not see a specific Object in the memory allocation terminal. What is the motivation for this change? If this is modified, it may impact the application since it won't be able to store pairing info to SNV.

    Please let me know if there are any further open questions I did not answer.