MSP430 memory addresses

Why don't you just declare a global array and let the linker place it and put its address into your code at link stage?

If the written content shall survive a reset, you'll have to tell the linker that the array shall stay uninitialized. It works without problem unless you recompile the code with a change in the global variables 8whcih could modve the address of the array). In this case, you can also assign a fixed address to the array, but this is compiler/linker specific stuff and not portable. See the IDE documentation for details.

I need it to survive reset as well as LPM3.5. So this means that the SRAM gets cleared every so often and it needs to come back and keep writing from the same address. I don't want it to rewrite over the old data every time it goes into LPM. Do you also mind giving some example code if there is some way to make the array stay after LPM?

Thanks,

-Omri

Omri,

Jens-Michael is saying that you need to declare the global variable as unitialized data so when the project is built, the toolchain knows not to include those variables in the section of stuff that gets initialized by cinit at bootup. Doing this will make the data persist between reset/LPMx.5 events.

This question has been asked before. http://lmgtfy.com/?q=MSP430+variables+in+FRAM

Here is the top result from Google: http://processors.wiki.ti.com/index.php/Creating_MSP430_FRAM_Variables_Using_CCS

The #pragma NOINIT(_your_variable_name_) before your variable declaration is key.

Omri Almog said:

I need it to survive reset as well as LPM3.5. So this means that the SRAM gets cleared every so often

A reset won't clear SRAM. LPM3.5 will,as it switches ram retention power off internally. However, after RESET (no matter for what reson, LPM ewake or power-on or whatever), the variables will be cleared usually, wheter in SRAM or FRAM, by the C init code. Unless you declare them as not to be initialized. CCS in legacy COFF mode didn't do this initialization. All variables that weren't explicitely initialized in code were left untouched at program start. in ELF mode, they are now set to 0.

How to tell the compiler to not initialize a variable is compiler/linker specific. Brian has already provided the solution of CCS.

Jens-Michael Gross said:

Brian has already provided the solution of CCS.

The links also provide an IAR example solution too.

Brian and Jens-Michael,

Thank you both for the replies. I can give this a try. I have three follow-up questions though:

1. We need as much data storage capability as possible. When modifying the linker command file using: 

MEMORY
{
    .............
    FRAM_VARS               : origin = 0xC200, length = 0x0080
    .............
}

I can look at the map file to see the size of my program (used in FRAM):

This way I know how much my program takes up. Am I right to take the total size of FRAM and subtract my program size to give me the max size I can put in my length field of my FRAM_VARS? Along the same lines, will FRAM_VARS take up the addresses from C200 to (C200+length)?  Does that mean C200+length and up to the end of FRAM will be where my program is written?

2. This second question is kind of related to the previous questions. Once I know the size available to me for my FRAM_VARS, I can get the # bytes available for storage. Am I correct to assume that: # of bytes a 2d char array will take up in FRAM =  (the width of the array)*(the length of the array)? (For the MSP430 architecture)

3.The example showed int, but I am assuming this works as well?:

#pragma SET_DATA_SECTION(".fram_vars")
unsigned char[width][length] time_data_array ;
#pragma SET_DATA_SECTION()

Thank you very much for your help, I hope I was clear enough in my questions! :)

-Omri

You are on the right track in regards to all three questions.

For a flash based part, the section length would need to be a multiple of the segment size (so that erase operation on data wouldn't blow away any code sections), but since you are in FRAM I think you are ok.

There's one thing to consider: the MSP430FRs memory protection mechanism.

Basically, all FRAM is writable. To protect the application, the C startup code that is linked will set a fixed border where variable space ends and program space begins (I think it is 50:50). Once this is done, you cannot write to program space anymore. Maybe some additional tweaks in the linker files are required here too to maximize the storage area.