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.

write to FRAM with PERSISTENT and NOINIT

Other Parts Discussed in Thread: MSP430FR2633

Hallo,

I am using the MSP430FR2633 with Version: 6.1.2.00015 and want to use the FRAM.

in the linker file I moved the .TI.noinit near to the .TI.persistent. Now it looks like this:

GROUP(ALL_FRAM)

{

GROUP(READ_WRITE_MEMORY)

{

.TI.persistent : {} /* For #pragma persistent */

.TI.noinit : {} //new by user /* For #pragma noinit */

}

    GROUP(ALL_FRAM)
    {
       GROUP(READ_WRITE_MEMORY)
       {
          .TI.persistent : {}                /* For #pragma persistent            */
          .TI.noinit  : {}    //new by user  /* For #pragma noinit                */
       }

For testing I did the following:

uint8_t 	tmp1;
uint8_t 	tmp2;
uint8_t 	tmp3;
uint8_t 	tmp4;

#pragma PERSISTENT(testFR)
uint8_t testFR=12;

	tmp1=testFR;

	testFR=34;
	__delay_cycles(1000);
	tmp2=testFR;

	testFR=44;
	// __delay_cycles(1000);
	tmp3=testFR;

	testFR=54;
	__delay_cycles(1000);
	tmp3=testFR;

It reads out the value 12 in all of the tmp variables. So it seems like there is no data written in the FRAM after allocation.

I also tried the #pragma NOINIT with the only difference of getting 255 instead of 12. Seems like this is the initial value but again no data written.

Do I have to unlock the FRAM first?

What am I missing?

  • it is CCS Version: 6.1.2.00015
    and Compiler TI v4.4.7
  • Hello,

    Yes, you have to enable FRAM writes before you can change the value of testFR stored in FRAM. This can be done using the line SYSCFG0 = FRWPPW | DFWP; and after you are finished altering the variable then you should use SYSCFG0 = FRWPPW | PFWP | DFWP; to return the FRAM to its write protected state. Further FRAM write examples are provided in the MSP430FR263x Code Examples package: www.ti.com/.../slac700

    If you really want to use NOINIT then make sure you've removed the previous .TI.noinit declaration from the RAM space, but I suggest you leave the command linker file at its default setup.

    Regards,
    Ryan
  • Hello Ryan,

    Thank you. With this lines I can write to FRAM.

    I have annother related problem now. The NOINIT writes the variables and after restart or power off they are still there. But after code download the variable is set back to 255. This behavour is different from the discription in the document:SLAA628–June 2014. In chapter 5.1 I found:
    "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."

    My assumption is that my variable ended up in the Program FRAM.

    Do you know how to take it in the Information FRAM?
    Is this FRAM2 in the linker file?

    Thank you,
    Georg
  • Hi Georg,

    The purpose of NOINIT is that it does not have an initial value, hence why it resets to 255 each time the code is downloaded. If you would like to define your variable with a value in mind then use PERSISTENT instead.

    Regards,
    Ryan
  • Hi Ryan,

    In my application I need to store a value calculated in my code and cannot have it changed by restart, power off or code download. Only my code should be able to change this value.
    This is why I tried to use NOINIT to store it to FRAM. But so far it is reset by Code download.
    My approach is to store it in a different partition than the code. But I cannot see where the partiotion is choosen in the linker.

    How can I change the partition of i.e. .TI.noinit in the linker file?

    Thank you
    Georg
  • I understand now, you are trying to store your variable inside the information memory so that it is not erased when you download a fresh code revision. This memory space is defined as INFOA by the linker file. You will have to make sure that your programmer does not alter the information memory space when downloading new code.

    Regards,
    Ryan

**Attention** This is a public forum