• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 54 subscribers
  • Views 1128 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.

Has anyone implemented a simple NVM system to set and get variables and their values, so they'll survive power-cycles?

Jonathan Griffiths
Prodigy 30 points
Other Parts Discussed in Thread: CC1310

I need a place to hold network information after setting up or joining a radio network.  I need to store a PAN Id, channel number/frequency, protocol type, etc.

I was thinking along the lines of U-Boot's system, whereby a simple ASCII text block is created, with the variable name and its value (as a string) is stored as simple <item>=<value> pairs.

Has anyone done this on the CC13xx/CC26xx?

  • 0
    TI__Expert 4635 points
    Hi Jonathan,

    how much data do you need to store and how often is it going to be written?

    The CC1310 datasheet (SWRS181) shows the high level flash parameters in section 5.10.4 Flash Memory Characteristics:
    - A full page or sector size is 4K if you are planning to work at a page level and you have 100K erase cycles.

    Regards,
    Garry
  • 0 in reply to Garry Clarkson
    Prodigy 30 points
    Hi Garry,

    Not very much data needs to be stored. I suspect at most 20 variables & their stringified values. 4Kbytes is easily large enough. For robustness we'd need a second page set aside to cope with the problem of power-cycling mid-way through an update. To avoid losing everything we'd need to copy the new RAM-based version of the text file to the "off" page with timestamp. That way, when we restart we can inspect both pages for validity and use the latest if we have a choice.

    I also suggest it won't get changed very often, so wear-levelling won't be an issue. Can you recommend 2 x 4K pages that will be out of the way from the standard place that "SmartRF Flash Programmer 2" writes the firmware?
  • 0 in reply to Jonathan Griffiths
    TI__Expert 4635 points

    Hi Jonathan,

    you should set these areas aside by creating your own "NVRAM" section definition(s) in the project linker .cmd file for the pages you need.  That way you can fix the size and position in memory of the flash block.  It is then removed from the available flash pool that the linker can use for code and you can use #pragma directives to instruct the linker to position the variables accordingly inline (assuming you are using the CCS ARM compiler):

    #pragma SET_DATA_SECTION("NVRAM")
int x;
int y;
#pragma SET_DATA_SECTION()

    You might want to create separate A and B pages. Unfortunately I don't have any ready code examples of using this in practice together with the necessary project to exercise the flashsafe API within DriverLib to read and write the flash pages in a thread safe manner.  Make sure that you don't accidentally overwrite or corrupt the .ccfg area at the top of flash which can lockout the JTAG and ROM Bootloader if set to the wrong values which can lock the device.

    Perhaps one of my colleagues in the tools the team can pick-up on the example code which handles flash update from here.

    Regards,

    Garry

  • 0 in reply to Garry Clarkson
    Prodigy 30 points

    Thanks, Garry.

    Will this area of NVM variable space stay in a constant place as the code grows with new features?  What I mean is that if I write to the NVM variable store in one build of the firmware, and then, a year later with many more features more added, I upgrade the device with the latest firmware - will the new firmware find the NVM area in the same place, still holding the values written there a year previously?

    If so, can you suggest an address for this NVRAM for use in the .cmd file?  Especially in light of your comment about corrupting the .ccfg area...

    Jonathan