MSP430FR57xx: How to put variables in FRAM (C program)

Iurii Vlasenko said:

const uint16_ foo;
I think that 'foo' will be in FRAM memory

This declares a constant value. A storage location whose content will never change.It usually makes only sense for arrays of precalculated data or if you need to pass values by reference for some reason. Or if it is only kown that the value is constant, but not known, which value this will be (e.g. a serial number that is not known at compile-time).
In any other case, it would be better to use a define instead. When the constant is used, the compiler can always use the value directly. No need to reference the storage location then.

However, things declared as const go into non-volatile memory. They are not expected to ever change and cannot be changed by C code at all.

Iurii Vlasenko said:

foo = bar;

Since foo is a constant, it is read-only. The only case in which this would be allowed to pass through without an error (even though I doubt that any compiler will make this difference) is when bar is also a constant with the same value. Then the assignment is of course void.

If you want to put a variable (that can be written to) into FRAM, you can do so by preceding it with a pragma that tells the linker to put it into modifiable FRAM data section. See the compiler/linker manual for details.

Thank you very much!

Jens-Michael Gross said:

a pragma that tells the linker to put it into modifiable FRAM data section. See the compiler/linker manual for details.

I've looked it up, but I liked another approach. 

#define FRAM_VARS_START (uint16_t*)0x1800

uint16_t *ParsInFRAM;

ParsInFRAM = CONF_VARS_START;

...

*(ParsInFRAM++ ) = ParsWk[i];

...

ParsIn[i] = *(ParsInFRAM++);

The value of FRAM_VARS_START points to the Informatiom Memory of MSP430FR5726.  It makes my code absolutely linked to the address, but it's OK for an array of configuration constants. And I can write to that location or read the constants in RAM (ParsIn[] or ParsWk[]). Now I try to organize a protection to this section - with a MPU of the MCU.

Thanks!

You explained all aspects of the question. "My mind is clear now"... (JC Superstar)

Still I think that limited and careful usage of "pointer" access (as I described earlier) may be accepted too. In small and simple projects, for example. Especially if I use information memory. Cannot imagin acidental double usage of it. Linker doesn't use it without special "pragmas", I think.

Besides, I'm not sure about the exact "pragma" way you say about :) Shall I use #pragma SET_DATA_SECTION? And, if I want the section to be located in a definite area (0x1800 infotmation memory), I have to tell Linker the 1-st address of that section. How?

Well, I have to grow up to it... 

Iurii Vlasenko said:

Shall I use #pragma SET_DATA_SECTION? And, if I want the section to be located in a definite area (0x1800 infotmation memory), I have to tell Linker the 1-st address of that section. How?

The linker has several sections defined in its control script. By default, the compiler adds linker information about putting code into TEXT section, variables into DATA section and so on. With the pragma, you tell the compiler to generate linker info for a different section then. Like the info memory sections which are defined (look into the linker command script for the exact names) but not normally used.

Iurii Vlasenko said:

Still I think that limited and careful usage of "pointer" access (as I described earlier) may be accepted too.

As long as you are sure that this code is the only code that does it, it should work.
The problems start when you use or re-use code in different projects and forget that some (more than one) is doing the same pointer access method. It simply takes usage of resources out of linker/compiler control and you therefore won't get any warnings.
Well, same is true for local variables too: no linker control, and the compiler doesn't know of any limitations in stack size. I have seen people declaring 1k of local array on an MSP with only 512 bytes ram. No errors, no warnings, just an instant stack overflow into vacant memory. so there is no proof. But if possible, one should use methods to reduce possible future problems right from the beginning.