• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 78 subscribers
  • Views 184 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.

MSP430FR5964: Preventing initialisation of NVS data on program load

Andrew McLaren
Intellectual 570 points
Part Number: MSP430FR5964

I've been having a play with the NVS utility in the MSP MCU FRAM Utilities, and almost have it working as expected, but not quite! The NVS data is being correctly being positioned in FRAM, and retained on restarts, but if I reload the code it is being reinitialised. I'm guessing its something trivial I am missing - hopefully someone can point me in the right direction. Following is a precis of what I have done, and where I am currently at. I'm using the GCC toolchain, and studio 10.4.

First up, the NVS storage is being assigned to the .persistent SECTION using the following;

uint8_t nvs_data[NVS_DATA_STORAGE_SIZE(sizeof(nvs_data_t))] __attribute__((section(".persistent"))) ;

From the map, and the debugger, this is all being located correctly in the .persistent section in FRAM (0x4xxx in the 5964 processor).

From the linker .ld  script for this processor, the appropriate section is;

/* This section contains data that is initialised during load
   but not on application reset. */
.persistent :
{
   . = ALIGN(2);
   PROVIDE (__persistent_start = .);
   *(.persistent)
   . = ALIGN(2);
   PROVIDE (__persistent_end = .);
} > FRAM

My first stab was that this should include a (NOLOAD) directive to suppress initialisation during load, but this appears to make no difference. From having a peek with the debugger, the NVS data has definitely been reinitialised before NVS gets to perform its own validation.

Any ideas where I am going wrong?

Andrew

  • 0
    Intellectual 570 points

    Found a very relevant comment on some similar issues with a .noinit section...

    By default mspflasher uses "-e ERASE_ALL" which clears all program memory (FRAM) to 0xFF. [Ref  MSPFlasher UG (SLAU654E) Table 1]. You might do better with "-e NO_ERASE" or maybe "-e ERASE_SEGMENT". 

    That seems to be exactly the situation I am seeing - the NVS storage comes back as 0xFF's.

    I've been trying to figure out how I can configure and/or suppress what is erased within CCS. Under the project properties, Debug -> MSP430 Flash Settings, there are some erasure options, but nothing that appears to prevent erasure completely, or somehow tailor in to a specific section. I imagine I could suppress a specific memory range, but this would tie the suppression tightly to the map of a specific build. The other option via this route would be to suppress erasure of the whole of the FRAM - probably minimal issues with this if i need to.

  • 0 in reply to Andrew McLaren
    Intellectual 570 points

    Haven't found any explicit way to suppress erasure using CCS. I tried setting erase to a specific address range from 0..0 (a bit of a crude idea) but this also erased everything. I took a stab that a null range was just ignored, so set the erase range to 0..1, and it's finally leaving the FRAM alone, and my NVS is surviving a reload. There has to be a better way?

  • 0 in reply to Andrew McLaren
    TI__Mastermind 32900 points

    My advise is that you can put your NVS in information memory.

    Then you can use the default erase setting.

  • 0 in reply to Eason Zhou
    Intellectual 570 points

    Unfortunately, at 4 x 128 bytes, Info memory segments are tiny, and not enough for what I need. Mapping a block of FRAM with NVS seemed to do exactly what was required, other than managing what is erased.

  • 0 in reply to Andrew McLaren
    TI__Mastermind 32900 points

    You can try By address Range setting

  • 0 in reply to Eason Zhou
    Intellectual 570 points

    At present that is exactly what I am doing.

    Since there doesn't see to be any way to define erasure in terms of what not to erase (for instance erase everything but this region), I've elected to go as close as I can get to an erase nothing strategy. Even this doesn't seem to be directly supported via CCS? As above, I've tried to tell it to erase everything from address 0 to 0, which would have done this, but it appears to ignore a null address range, and just goes ahead and erases everything. I've currently got it erasing everything from address 0 to 1, which doesn't appear to be causing any issues, and leaves the rest of the memory space alone.

    With the advent of FRAM, and the non-volatile options available to be exploited (which is what the FRAM Utilities are doing), this feels a bit limiting. It would be nice if there were real options to suppress erasure, as they are essential for non-volatile models to work. If this could be taken to a memory section level, it would be really easy to create an NVS section, and tell the loader to leave that alone (I don't know if the loader has access to that level of memory metadata, so may not even be technically possible?). 

    Thanks for the comments. I'll close this off, as pretty sure I've reached the end of that particular road!

    Andrew

**Attention** This is a public forum