CCS/MSP430FR2355: FRAM questions and variables

You need to make sure there's a reference (somewhere) in your program to the variables you're creating, or the linker will toss them out as "unused". ("volatile" doesn't work for this since that's a C concept).

PERSISTENT sounds like the sort of thing you want. A persistent variable is initialized every time you load new code, but not at every reset. I'm not quite sure why your non-default userID needs to be in non-volatile memory since you want it to be cleared (re-initialized) on every reset.

Related features are NOINIT, LOCATION, and DATA_SECTION, which do variants of this.

Information memory is the usual place to store configuration data.

I don't know what you mean by "hard board reset". How does this differ from a power on reset? How can your software tell the difference?

The non-default userID will be static and needs to be retained over reset as well (PERSISTENT?)....that is the units will ship with default, user will create a system ( ie....userID).....This will be static and will remain even during power down / power up cycles HOWEVER the user does have a hardware reset button which would allow him to go back to the default and reflash the user ID with a new user number.....

With that said I am guessing PERSISTENT is the right choice for userID as well?

I will look into the LOCATION/DATA SECTION pragmas....I hope I can do these things within the c files and don't have to monkey with the linker.cmd file as that seems very cryptic???

Thanks

Steve

Each of that set of directives provides a slightly different usage model. PERSISTENT will get you going.

As David pointed out, Information Memory is a fairly standard place to put such things. You can do this with DATA_SECTION(<varname>,".info"). This has the advantages that:

1) Information Memory (aka "Data FRAM") is normally write-protected, where persistent data (on the FR2355) is read/write. You can open/close it by wiggling SYSCFG0:DFWP

2) The linker won't put anything in .info on its own, so the variable won't move unless you move it.

3) If you don't supply an initialization value, it won't be overwritten during download. [See also Properties->Debug->Flash Settings]. That in turn means that you need to figure out when it does need to be initialized.

You can do it either way without touching the linker file.

Bruce....

I've read and re-read your answer above but am somewhat confused.....So I was able to use (before main like a global variable)

#pragma PERSISTENT(permanent_Info)
char permanent_Info[9] = {'1', '2', '3', '4', '0', '0', '0', '0', '0'};

and then later in the code via logic I did an assignment

                            permanent_Info[8] = tmp;

and it worked (ie I did a soft reset in CCS and the info remained)....so

1.  Is there a way in CCS to debug where you DON'T reload code?  I would like to power the board down and re-connect with CCS to view the permanent_Info space and see that it is still there.....typically after I power down the board I have to hit debug to connect and that will erase the permanent_Info[8] space.

2. I see the above loads the variable at 0x8000.....This seems to be at the bottom end of what the data sheet calls as "Main : code memory"....I'm guessing that if I add #pragma DATA_SECTION permanent_Info[9].info along with using LOCATION somewhere between 0x19FF and 0x1800 (once again per data sheet "Information FRAM") then I would not see it get loaded each time I run the debugger / shutdown the system as long as I keep Flash settings at Erase main only?

3.  Now assuming #2 is correct which I will experiment with, should I be tickling SYSCFG0.DFWP just before I write the permanent_Info[8] character?

.....I have since added the following lines to the code before main:

#pragma PERSISTENT(permanent_Info)
#pragma DATA_SECTION (untouchables,."info")

char permanent_Info[9] = {'1', '2', '3', '4', '0', '0', '0', '0', '0'};
#pragma LOCATION(permanent_Info, 0x1800)

CCS builds and I can see my variable at 0x1800 now....Does the above look correct?  I still cannot see "untouchables" in the .cmd or .map anywhere.....Do I need to do something else maybe?

Thanks

Steve

That was the behavior I (thought I) was describing. On some devices, PERSISTENT (per se) data is read-only, but not on the FR2355.

1) "<right-click on the project>->Debug As->Debug Configurations->Program->Load Symbols Only". This setting is sticky, so when you want to really download you'll have to change it back. 

2) If you use PERSISTENT, you're required to give it an initial value, and so it will set that initial value on a download.

If you use DATA_SECTION(,".info"): (a) if you give it a value (C initializer), a download will put that value there (b) if you don't give it a value download will not touch it. 

3) As I mentioned before, if you don't have a reference to "untouchables" somewhere in your program the linker will throw it away.

[Edit: Yes, if it's in Information Memory you need to clear/set DFWP around the update. In my world, that's a feature.]

Bruce...

Thank you very much for your help!  Below is my code and it seems to be working as expected...Please comment if you see anything I am doing wrong...As a hardware guy working with the pragma / linker seems a little esoteric...almost like linux :)

#pragma DATA_SECTION (permanent_Info,".info")
#pragma LOCATION(permanent_Info, 0x1800)

char permanent_Info[9] = {'1', '2', '3', '4', '0', '0', '0', '0', '0'};

within the code I have:

                            SYSCFG0 =0xA501;  //unlock write to info memory
                            permanent_Info[8] = tmp;
                            SYSCFG0 =0xA503;  //lock write to info memory

This seems to work...I see permanent_Info in the .map file, not in the .cmd file...guessing that is not a big deal as the #pragma replace me altering 
the .cmd file to do the same thing.....

The section name ".info" appears in the .cmd file -- that's what ties this together.