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/MSP430FR5972: store configuration items in FRAM which is persistent across both power cycle and a reprogramming in CCS

Part Number: MSP430FR5972

Tool/software: Code Composer Studio

Would you mind taking a moment to consider the below question please?

 

We want to store configuration items in MSP430FR5972 FRAM which is persistent across both power cycle and a reprogramming in CCS.

 

A power cycle does retain config, however a CCs program download initialises the config data even when defined as #pragma NOINIT

 

SLAA628 mentions the use of NOINIT and PERSISTENT pragmas and mentions a linker command file modification is necessary of using NOINIT.

 

I can’t find a reference to what linker changes are required.

 

5.1 TI Code Composer Studio In CCS, there are two C language pragma statements that can be used: #pragma PERSISTENT and #pragma NOINIT. Before using either of these pragmas, see Section 3.4.1 on linker command file requirements as well as Appendix A for important information regarding CSSv6.0.0 to ensure that variables declared using either pragma directive are stored in FRAM memory. Also, for more detailed information on these pragma directives, see the MSP430 Optimizing C/C++ Compiler User’s Guide (SLAU132). PERSISTENT causes variables to not get initialized by the C startup routine, but rather the debug tool chain initializes them for the first time as the application code is loaded onto the target device. Subsequently, those variables do not get initialized, for example, after a power cycle as they have been completely excluded from the C startup initialization process. Declaring variables as PERSISTENT causes them to get allocated into the .TI.persistent linker memory segment. For important information regarding CSSv6.0.0, see Appendix A. SLAA628–June 2014 MSP430™ FRAM Technology – How To and Best Practices 5 Submit Documentation Feedback Copyright © 2014, Texas Instruments Incorporated Ease-of Use Compiler Extensions for FRAM www.ti.com Here is a code snippet showing how the variable is declared as persistent: #pragma PERSISTENT(x) unsigned int x = 5; NOINIT works similar to PERSISTENT but the variables are never initially initialized by the project’s binary image file and the debug tool chain during code download. Declaring variables as NOINIT causes them to get allocated into the .TI.noinit linker memory segment. Note that unlike PERSISTENT, variables declared as NOINIT do not get located in FRAM by the default linker command files, requiring a minor modification of the linker command file if such functionality is required. Here is a corresponding code snippet: #pragma NOINIT(x)

 

We are using CCS Version: 6.1.3.00033

 

Also, CCS has Erase options (below) which still results in wiping configuration data.

 

Many thanks in advance,

  • Hi!
    In my msp430fr57xx projects, I use an Information Memory to store my persistent variables. It is not destroyed during reprogramming with SWB (though it wasn't the reason I put them there).
    I hope it may be the same with your chip.

    Regards,
    Yury
  • hi Yury,

    Thank you for the prompt reply. Unfortunately I need a LOT of configuration data which exceeds info area size.

    regards
  • Well, I'm ready to quit. Almost :)
    I read about IP Encapsulation Segment - isn't it the solution?
    slau367:
    Only program code executed from the IPE-segment can access data stored in this segment. The access
    rights are evaluated with each code access. Each code access outside of the IP-protected area
    deactivates the data access into the IPE-segment. JTAG or DMA cannot access the IPE-segment.

**Attention** This is a public forum