MSP430FR6989, Unable to use FRAM2 with #pragma PERSISTENT

Also, here are how the two FRAM sections are defined in the linker file:

    FRAM                    : origin = 0x4400, length = 0xBB80
    FRAM2                   : origin = 0x10000,length = 0x14000

Right, I think it is pretty apparent that I have to split the data between the two sections. My main question is how do I do that??

I can't do it just using the PERSISTENT directive because that is what I am currently doing and it obviously won't split the data between the two locations.

I don't think I can have my application write directly to either section without the risk of writing over any code/data placed there by the linker. Or is that not true? Whenever I try to write directly to one of those FRAM sections, the .map file doesn't reflect it:

#define FRAM1_ADDR	0x4400

uint8_t *p_FRAM1 = (uint8_t *)FRAM1_ADDR;

for(i = 0; i < 2000; i++)
{
    p_FRAM1[i] = 7;
}

Again, there's got to be a way to utilize the second section of FRAM (FRAM2). Anyone have any idea how?

Hi Leo,

Thanks for the response and sorry for my long delay. I'm just getting back to this and tried out your suggestion. I'm finding that when I try to compile, though, that I get these warnings:

#10015-D output file "Foucault.out" cannot be loaded and run on a target system Foucault C/C++ Problem

<a href="file:/c:/ti/ccsv6/tools/compiler/dmed/HTML/17003.html">#17003-D</a> relocation from function "SMemory" to symbol "_ZN7SMemory10m_stepDataE" overflowed; the 17-bit relocated address 0x10000 is too large to encode in the 16-bit field (type = 'R_MSP430X_ABS16' (15), file = "./Services/SMemory.obj", offset = 0x0000001e, section = ".text:_ZN7SMemoryC1Ev") 

Here are snippets from my updated linker file:

MEMORY
{
    TINYRAM                 : origin = 0x0006, length = 0x001A
    PERIPHERALS_8BIT        : origin = 0x0020, length = 0x00E0
    PERIPHERALS_16BIT       : origin = 0x0100, length = 0x0100
    RAM                     : origin = 0x1C00, length = 0x0800
    INFOA                   : origin = 0x1980, length = 0x0080
    INFOB                   : origin = 0x1900, length = 0x0080
    INFOC                   : origin = 0x1880, length = 0x0080
    INFOD                   : origin = 0x1800, length = 0x0080
    FRAM                    : origin = 0x4400, length = 0xBB80
//  FRAM2                   : origin = 0x10000,length = 0x14000
    DATA1                   : origin = 0x10000,length = 0x14000
    JTAGSIGNATURE           : origin = 0xFF80, length = 0x0004, fill = 0xFFFF
    BSLSIGNATURE            : origin = 0xFF84, length = 0x0004, fill = 0xFFFF
    IPESIGNATURE            : origin = 0xFF88, length = 0x0008, fill = 0xFFFF
    INT00                   : origin = 0xFF90, length = 0x0002
    INT01                   : origin = 0xFF92, length = 0x0002
.
.
.
.
}

SECTIONS
{
    GROUP(RW_IPE)
    {
        GROUP(READ_WRITE_MEMORY)
        {
           .TI.persistent : {}              /* For #pragma persistent            */
           .cio           : {}              /* C I/O Buffer                      */
           .sysmem        : {}              /* Dynamic memory allocation area    */
        } PALIGN(0x0400), RUN_START(fram_rw_start)

        GROUP(IPENCAPSULATED_MEMORY)
        {
           .ipestruct     : {}              /* IPE Data structure                */
           .ipe           : {}              /* IPE                               */
           .ipe_const     : {}              /* IPE Protected constants           */
           .ipe:_isr      : {}              /* IPE ISRs                          */
           .ipe_vars      : type = NOINIT{} /* IPE variables                     */
        } PALIGN(0x0400), RUN_START(fram_ipe_start) RUN_END(fram_ipe_end) RUN_END(fram_rx_start)
    } > 0x4400

    .cinit            : {}  > FRAM          /* Initialization tables             */
    .pinit            : {}  > FRAM          /* C++ Constructor tables            */
    .init_array       : {}  > FRAM          /* C++ Constructor tables            */
    .mspabi.exidx     : {}  > FRAM          /* C++ Constructor tables            */
    .mspabi.extab     : {}  > FRAM          /* C++ Constructor tables            */
    .const            : {} >> FRAM          /* Constant data                     */
    .text:_isr        : {}  > FRAM          /* Code ISRs                         */
    .text             : {} >> FRAM          /* Code                              */

    StepDataSpace     : {} > DATA1          /* Step data storage                 */

.
.
.
.
}

Basically, I designated all of FRAM2 to my new area called DATA1. I then assigned my new section, StepDataSpace, to DATA1. I also removed all other uses of FRAM2 so that there isn't a conflict. Then, in my source code, I declare an array that is suppose to be allocated to the new StepDataSpace:

#define STEP_DATA_BUF_SIZE_BYTES 10

/**
 * Initialize static member variables
 */
#pragma DATA_SECTION("StepDataSpace")
uint8_t SMemory::m_stepData[STEP_DATA_BUF_SIZE_BYTES] = {0};

Any thoughts on why I'm getting these compiler warnings??
Thanks!

Hi Leo,

Thanks for the response and sorry for my long delay. I'm just getting back to this and tried out your suggestion. I'm finding that when I try to compile, though, that I get these warnings:

#10015-D output file "Foucault.out" cannot be loaded and run on a target system Foucault C/C++ Problem

<a href="file:/c:/ti/ccsv6/tools/compiler/dmed/HTML/17003.html">#17003-D</a> relocation from function "SMemory" to symbol "_ZN7SMemory10m_stepDataE" overflowed; the 17-bit relocated address 0x10000 is too large to encode in the 16-bit field (type = 'R_MSP430X_ABS16' (15), file = "./Services/SMemory.obj", offset = 0x0000001e, section = ".text:_ZN7SMemoryC1Ev") 

Here are snippets from my updated linker file:

MEMORY
{
    TINYRAM                 : origin = 0x0006, length = 0x001A
    PERIPHERALS_8BIT        : origin = 0x0020, length = 0x00E0
    PERIPHERALS_16BIT       : origin = 0x0100, length = 0x0100
    RAM                     : origin = 0x1C00, length = 0x0800
    INFOA                   : origin = 0x1980, length = 0x0080
    INFOB                   : origin = 0x1900, length = 0x0080
    INFOC                   : origin = 0x1880, length = 0x0080
    INFOD                   : origin = 0x1800, length = 0x0080
    FRAM                    : origin = 0x4400, length = 0xBB80
//  FRAM2                   : origin = 0x10000,length = 0x14000
    DATA1                   : origin = 0x10000,length = 0x14000
    JTAGSIGNATURE           : origin = 0xFF80, length = 0x0004, fill = 0xFFFF
    BSLSIGNATURE            : origin = 0xFF84, length = 0x0004, fill = 0xFFFF
    IPESIGNATURE            : origin = 0xFF88, length = 0x0008, fill = 0xFFFF

SECTIONS
{
    GROUP(RW_IPE)
    {
        GROUP(READ_WRITE_MEMORY)
        {
           .TI.persistent : {}              /* For #pragma persistent            */
           .cio           : {}              /* C I/O Buffer                      */
           .sysmem        : {}              /* Dynamic memory allocation area    */
        } PALIGN(0x0400), RUN_START(fram_rw_start)

        GROUP(IPENCAPSULATED_MEMORY)
        {
           .ipestruct     : {}              /* IPE Data structure                */
           .ipe           : {}              /* IPE                               */
           .ipe_const     : {}              /* IPE Protected constants           */
           .ipe:_isr      : {}              /* IPE ISRs                          */
           .ipe_vars      : type = NOINIT{} /* IPE variables                     */
        } PALIGN(0x0400), RUN_START(fram_ipe_start) RUN_END(fram_ipe_end) RUN_END(fram_rx_start)
    } > 0x4400

    .cinit            : {}  > FRAM          /* Initialization tables             */
    .pinit            : {}  > FRAM          /* C++ Constructor tables            */
    .init_array       : {}  > FRAM          /* C++ Constructor tables            */
    .mspabi.exidx     : {}  > FRAM          /* C++ Constructor tables            */
    .mspabi.extab     : {}  > FRAM          /* C++ Constructor tables            */
    .const            : {} >> FRAM          /* Constant data                     */
    .text:_isr        : {}  > FRAM          /* Code ISRs                         */
    .text             : {} >> FRAM          /* Code                              */

    StepDataSpace     : {} > DATA1          /* Step data storage                 */

Basically, I designated all of FRAM2 to my new area called DATA1. I then assigned my new section, StepDataSpace, to DATA1. I also removed all other uses of FRAM2 so that there isn't a conflict. Then, in my source code, I declare an array that is suppose to be allocated to the new StepDataSpace:

#define STEP_DATA_BUF_SIZE_BYTES 10

/**
 * Initialize static member variables
 */
#pragma DATA_SECTION("StepDataSpace")
uint8_t SMemory::m_stepData[STEP_DATA_BUF_SIZE_BYTES] = {0};

Any thoughts on why I'm getting these compiler warnings??
Thanks!

Katie,

Thank you so much for such a detailed and helpful response! I don't think I've ever received such a helpful response as this one. I do have one question. I may end up changing the amount of memory reserved for data storage, but I went ahead and tried compiling with the ranges you had outlined in your example.

The problem I run into is if I allocate my two data buffers as you had done in your c file (one at 0x14000, and the other at 0xA000), I get errors saying that the code is too large to fit into memory. If, however, I subtract 0x400 from 0xA000 (0x9F80) and use that, it uses up every last bit of memory in DATA_FRAM:

#define STEP_DATA_BUF_1_SIZE_BYTES  0x9F80
#define STEP_DATA_BUF_2_SIZE_BYTES  0x14000

#pragma PERSISTENT
uint8_t SMemory::m_stepData1[STEP_DATA_BUF_1_SIZE_BYTES] = {0};
#pragma PERSISTENT
uint8_t SMemory::m_stepData2[STEP_DATA_BUF_2_SIZE_BYTES] = {0};

My question is, what is using that extra 0x400 bytes? When I look at the memory allocation gui, there's nothing in there taking up those 0x400 bytes. My only thought is that I am using C++ and perhaps that is a factor?

Let me know what you think and thanks again!

Hi Katie,

The custom linker file I have been using has worked great so far. However, I am having a new issue. For the extended address range, I have declared a single uint8_t array (m_stepData2) as PERSISTENT and set its length so that it occupies all of the space from 0x10000 - 0x24000.

#define STEP_DATA_BUF_2_SIZE_BYTES  0x14000U

#pragma PERSISTENT
uint8_t SMemory::m_stepData2[STEP_DATA_BUF_2_SIZE_BYTES] = {0};

I also have a function called WriteStepData that writes to this array. When testing in my debug build with the optimization level set to 0, everything works fine and if I look in the Memory Allocation GUI I can see that m_stepData2 is taking up all of the DATA_FRAM2 segment we declared in the linker:

The problem I have now is if I change the optimization level from 0 to level 4 (Whole Program Optimizations), my calls to WriteStepData result in this warning:

I seem to have narrowed it down to changing the optimization level that generates this warning. The problem is that I need to be able to use a high level of optimization to reduce the code size to a manageable level. 

Do you have any insight into how I can still use the extended address space AND still keep the optimization level 4 enabled?

Great, thanks Katie. Here's the link to other post:

https://e2e.ti.com/support/development_tools/compiler/f/343/t/484136

Hi Katie,

This thread was super helpful for what we were wanting to do. But I have some questions for you in order to make this more custom to our project. In our project we want to save three variables that are 4 bytes long each and since FRAM2 is much longer than that I thought I could somehow manipulate it in the the linker file and separate them out that way. But when I did that, I couldn't write any values into these persistent variables in my main code. Also in the memory allocation these new memory addresses weren't created which is why I know it's not writing to it. Only FRAM and FRAM5 are showing. Could you please guide me into doing this? 

Here is where I manipulated FRAM2 and broke it up to create the memory I want to store each persistent variable with. 

MEMORY
{
    TINYRAM                 : origin = 0x0006, length = 0x001A
    PERIPHERALS_8BIT        : origin = 0x0020, length = 0x00E0
    PERIPHERALS_16BIT       : origin = 0x0100, length = 0x0100
    RAM                     : origin = 0x1C00, length = 0x0800
    INFOA                   : origin = 0x1980, length = 0x0080
    INFOB                   : origin = 0x1900, length = 0x0080
    INFOC                   : origin = 0x1880, length = 0x0080
    INFOD                   : origin = 0x1800, length = 0x0080
    FRAM                    : origin = 0x4400, length = 0xBB80
    
    FRAM2		    : origin = 0x10000, length = 0x0020 //4 bytes
    FRAM3		    : origin = 0x10020, length = 0x0020 //4 bytes
    FRAM4                   : origin = 0x10040, length = 0x0020 //4 bytes
    FRAM5                   : origin = 0x10060, length = 0x13FA0 //remaining

And then I just thought I could move .TI.persistent from FRAM into the same section you did before, like so:

SECTIONS
{
  GROUP(RW_IPE)
    {
        GROUP(READ_WRITE_MEMORY)
        {
           //.TI.persistent : {}              /* For #pragma persistent            */
           .cio           : {}              /* C I/O Buffer                      */
           .sysmem        : {}              /* Dynamic memory allocation area    */
        } PALIGN(0x0400) > DATA_FRAM, RUN_START(fram_rw_start) RUN_START(fram_rx_end)

       GROUP(IPENCAPSULATED_MEMORY)
       {
          .ipestruct     : {}              /* IPE Data structure                */
          .ipe           : {}              /* IPE                               */
          .ipe_const     : {}              /* IPE Protected constants           */
          .ipe:_isr      : {}              /* IPE ISRs                          */
          .ipe_vars      : type = NOINIT{} /* IPE variables                     */
        } PALIGN(0x0400), RUN_START(fram_ipe_start) RUN_END(fram_ipe_end) RUN_END(fram_rx_start)
    } > 0x4400
    .TI.persistent : {} >> FRAM2 | FRAM3 | FRAM4 | FRAM5 /* For #pragma persistent            */

Hi Cassandra,

If you use #pragma PERSISTENT when declaring your variables, then you can simply treat them just like variables in RAM as far as reads and writes, except that they will be placed somewhere in the FRAM by the linker and will be retained through power loss because they are non-volatile - you don't need to use them like a saved copy of something, but can just use them in your normal application operation all the time as if they were in RAM, but on a power-cycle they won't be lost. You don't need to care about where they are placed - in the original post, the only reason Robert cared about placement was because he was storing so much data it could not all fit in lower FRAM. When your code comes back up, it will know not to overwrite the persistent variables and you won't have to re-declare any variables because these are the variables, they were just retained. PERSISTENT tells the toolchain that you want to load these values at program load when you very first program the device, but after that the compiler has set it in its C initialization code to not overwrite whatever values are contained there at each power cycle. Does this make sense? You can see more information in www.ti.com/lit/pdf/slau132 section 5.11.20 the NOINIT and PERSISTENT pragmas.

You can try with a simple test program you can run on the MSP-EXP430FR6989 Launchpad:

#include <msp430.h> 

#pragma PERSISTENT (count)
unsigned int count = 0;

unsigned char i = 0;

/*
 * main.c
 */
void main(void) {
    WDTCTL = WDTPW | WDTHOLD;	// Stop watchdog timer

    P1OUT &= ~BIT0;
    P1DIR |= BIT0; 			//LED init
    PM5CTL0 &= ~LOCKLPM5; 	//unlock GPIOs
	
	while(1)
	{
		//blink LED current count # of times
		for (i = 0; i <= count; i++)
		{
			P1OUT |= BIT0; //LED on
			__delay_cycles(50000);
			P1OUT &= ~BIT0;
			__delay_cycles(50000);
		}
		count++;
		if(count >= 5)
			count = 0;
		__delay_cycles(2000000); //delay so you can tell what the count is
	}
}

Simply load that (use the default, unmodified linker file that is built into CCS) and end the debug session. The code blinks the LED on P1.0 counting up between 1 and 5 times with a delay in between.  Running stand-alone, you'll see that if you unplug the board, say between 2 blinks and 3 blinks, that when you plug it back in it starts from 3 blinks because it has retained count. Notice how in the code, I didn't have to do anything special with the code or linker to enable this at all - I use it like a normal RAM variable. The only thing I had to do was use #pragma PERSISTENT.

Regards,

Katie

Katie,

Ah...I figured out what I needed to do, and you were right I didn't need to edit my linker file. I feel so silly since it's so easy too! So I know that all I have to do is use #pragma PERSISTENT and use my variable as if normal. The thing that got me and made me make it more complicated is that I thought we could only have one #pragma PERSISTENT variable. And I wanted to have three in my case. So my colleague and I were talking that we needed to shift all three data variables into this one PERSISTENT variable, WRONG!

Like I said, I feel so silly! Here is my own sample code that I am doing that works with more than one PERSISTENT variable.

#include <msp430.h>
#pragma PERSISTENT(corrected)
unsigned long corrected = 0;

#pragma PERSISTENT(uncorrected)
unsigned long uncorrected = 0;

#pragma PERSISTENT(factor)
unsigned long factor = 0;


int main(void) {
    WDTCTL = WDTPW | WDTHOLD;               // Stop watchdog timer
    PM5CTL0 &= ~LOCKLPM5;                   // Disable the GPIO power-on default high-impedance mode
                                            // to activate previously configured port settings
    P1DIR |= 0x01;                          // Set P1.0 to output direction

    for(;;) {

        volatile unsigned int i;            // volatile to prevent optimization

        P1OUT ^= 0x01;                      // Toggle P1.0 using exclusive-OR
        corrected = 36;
        uncorrected = 1;
        factor = 1.24;

        i = 10000;                          // SW Delay
        do i--;
        while(i != 0);
    }
}

Thanks Katie,

I am using MSP430FR6989 launchpad, these modifications in linker file helped me to store data in FRAM.