• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 54 subscribers
  • Views 621 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CCS/CC1352R: NVS not usable in project zero

spanky
Expert 2710 points
Part Number: CC1352R

Tool/software: Code Composer Studio

I would like to write some data to internal NVS using the project zero example. After a great deal of frustration, I found that the osal code is using that space after I write to it.

So digging around I found osal_snv_read osal_snv_write calls and it "appears" that I should be using those. Unfortunately, I have no idea how or why, and where (i.e. what space can I use?). Any help would be appreciated. I would like to eventually use OAD, but I dont even know how to turn that off to reclaim "normal" NVS read & write operations.

  • 0
    TI__Mastermind 33460 points

    Hello,

    We have section explaining the SNV architecture, including its location and sample code here:

    http://dev.ti.com/tirex/content/simplelink_cc13x2_sdk_2_20_00_71/docs/ble5stack/ble_user_guide/html/ble-stack-common/flash_memory_cc26x2_cc13x2.html#flash

    While theoretically possible to use the NVS directly, or to create another region that not overlapping with the stack, we recommend using the OSAL SNV mechanism for the following reasons:

    1. You get compaction logic for free

    2. It is more flash efficient to share with the stack, as the stack (in normal use cases) will not utilize the full NV region (unless you have a very very large number of bonding records)

    Here is the SNV sample code: http://dev.ti.com/tirex/content/simplelink_cc13x2_sdk_2_20_00_71/docs/ble5stack/ble_user_guide/html/ble-stack-common/flash_memory_cc26x2_cc13x2.html#lst-snv-api-usage

    Here is where we define the internal flash NVS region:

    #if !defined(NO_OSAL_SNV)
#if defined(__TI_COMPILER_VERSION__)

/*
 * Place uninitialized array at NVS_REGIONS_BASE
 */
#pragma LOCATION(flashBuf, NVS_REGIONS_BASE);
#pragma NOINIT(flashBuf);
static char flashBuf[REGIONSIZE];

#elif defined(__IAR_SYSTEMS_ICC__)

/*
 * Place uninitialized array at NVS_REGIONS_BASE
 */
static __no_init char flashBuf[REGIONSIZE] @ NVS_REGIONS_BASE;

    Where above  NVS_REGIONS_BASE = 0x48000.

    This means the last page of flash is reserved for CCFG (and BIM in the OAD case).  The NV region will be placed just before the final page.

  • 0 in reply to Sean2
    Expert 2710 points

    According to the docs it looks like my first parameter to osal_snv_read/osal_snv_write should be:

    #define BLE_NVID_CUST_START             0x80  //!< Start of the Customer's NV IDs
#define BLE_NVID_CUST_END               0x8F  //!< End of the Customer's NV IDs

    It sounds like this is an item number and not a byte offset like in the standard NVS calls? I.e. I can have 16 of my "items" stored without stepping on the BLE stuff. I'm not too clear on what an "item" is here because in the standard NVS stuff its a byte, but here it seems larger?

    In projectzero, it uses BLE_NVID_CUST_START, but only appears to write one byte, so that is my confusion.

    The documentation and example you linked writes 4 bytes, but I cant find the upper limit, or really clarification that I have more than 16 bytes to write to.

    If I want to write my own data in projectzero, do I send osal_snv_write 0x81 as the first parameter? and how big can my item be?

  • 0 in reply to spanky
    TI__Mastermind 33460 points
    Hello,

    You're correct about the first parameter. It is an ID and not an address.

    >> I'm not too clear on what an "item" is here because in the standard NVS stuff its a byte, but here it seems larger?
    An item is however large the length is provided on initialization. Depending on whether or not you have OSAL_SNV_UINT16_ID defined, the length is only limited by the NV space itself and the max storage in an unsigned 8 or 16 bit number.

    >> If I want to write my own data in projectzero, do I send osal_snv_write 0x81 as the first parameter? and how big can my item be?
    0x81 is an acceptable first argument. In general an ID is just a mapping to "some data" it can be any structure you like.
    Since SNV manages compaction for you, you are no longer writing to a specific address (as flash needs to be erased before it can easily be updated), you are instead working with an ID. SNV manages the ID to address translation for you.

    The size of the item is bounded by OSAL_SNV_UINT16_ID and either 8 or 16 bit unsigned. Note that lengths must be aligned on a NV word size boundary.