• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 80 subscribers
  • Views 611 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.

MSP430FR5969: Mapping out SRAM entirely

Matthew DeMars
Prodigy 50 points
Part Number: MSP430FR5969

Hello,

I am writing a program for an MSP430FR5969-SP and I need to configure memory so that anything that normally resides in SRAM is in the FRAM region (at 0x4400, not FRAM2 at 0x10000). I know that putting the stack in FRAM will incur a performance hit, but our application precludes any use of the SRAM.

My idea is to manually configure the MPU with two regions, one for code and one for everything else:

 

I’ve been able to move everything successfully to the FRAM region except for this block:

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)

 

There are two reasons I don’t want to just leave this block in FRAM and make FRAM the code segment:

  1. The ISR code has to be located in the lower FRAM area because that area can be accessed with 16-bit addresses and the ISR vectors are 16-bit addresses
  2. When I move my .text and ISR code segment to FRAM2, it fills up most of FRAM2, and I still have more code to add.

Can you provide me with specific instructions for how to accomplish this? Thank you

  • 0
    Guru 24385 points

    ISRs shouldn't be a problem because there is an attribute to force a function into lower FRAM and the compiler usually applies that automatically to anything with the interrupt attribute.

    If you use dynamic memory (malloc() and friends) then you are going to have trouble as this starts from the end of allocated memory in the bss. If you don't use dynamic memory allocation then it being in SRAM shouldn't be a problem.

  • 0 in reply to David Schultz
    Prodigy 50 points

    Thank you for your help David. First, I need to say that I copied the wrong MPU configuration picture into my original text above. This picture below is the one that I meant to show:

    I don't use dynamic memory allocation in my program, so that is not an issue. I was successfully able to get everything in FRAM, with nothing in SRAM. And the ISRs work. However, there is still an issue which is related to a variable that I have declared as persistent using the PERSISTENT pragma. It puts it into the code area, as shown here:

    I have configured the MPU to disallow writes in the FRAM area. When the program tries to write the persistent variable, and MPU exception occurs and the program won't run. I can get it to run by adding write permission to the FRAM area in the MPU configuration, but since the application code is no longer protected against unintended writes, there would be little point to enabling the MPU. 

    I want to use the MPU. Is there a way I can put the .TI.persistent segment in FRAM2?

  • 0 in reply to Matthew DeMars
    Guru 24385 points

    If you really have mapped out SRAM entirely then I don't see why you are using the persistent attribute. All of your variables should be in FRAM (or FRAM2) and by default persistent. (Except for initialization at reset.)

  • 0 in reply to David Schultz
    Prodigy 50 points

    That was my initial belief: that I don't need the #pragma PERSISTENT declaration on the line before my global variable anymore. But I change the value of the variable to a non-zero value (50). I confirm that the variable contains 50. I then power-cycle the MSP430 and look at the variable's value after power up. It is zero. This sequence is always repeatable. At this point I've been assuming that without the PERSISTENT pragma, the compiler is treating the global variable as it would as if it were in SRAM, by initializing it to zero. This shouldn't be happening?

  • 0 in reply to Matthew DeMars
    Prodigy 50 points

    Here is my memory allocation with the PERSISTENT pragma present:

  • +1 in reply to Matthew DeMars
    Guru 24385 points

    The C runtime startup code always zeroes out the bss and a variable without an initializer is placed in the bss. The attribute noinit should disable any startup initialization for the particular variable it is applied to.

**Attention** This is a public forum