MSP430FR5969 memory organization

Usually, the Linker can generate a Map List telling you how the memory are allocated. Turn-on that option, and examine the Map List.

old_cow_yellow said:

Usually, the Linker can generate a Map List telling you how the memory are allocated. Turn-on that option, and examine the Map List.

HI,

do you mean the window that shows you during the debug session the values stored in the memory?

If yes I 'm already using that. This is how i can see when i'm actually storing data or not where i want.

I would like to know if it possible to know , before the debugging phase, where the code will be stored and so where i will be able to store data

thanks for your kind reply

best regard

irene

No, I assume you use a PC to run a "cross" Compiler/Assembler/Linker of some sort. That PC program usually have the option of generating a text file (or HTML file) on that PC to tell you how it intend to use the memory in your MSP chip. This is done without touching your MSP chip. You do not even need a MSP to do this.

This file is usually referred as the "Link List", "Map List", "Link Map", "Map File", or something like that depending on which Compiler/Assembler/Linker you use.

Irene,

OCY's reply will tell you where the linker placed all of the code/data of the program when it was done being linked.

In addition, there is a thing called a linker command file (in CCS I think it has .cmd extension, in IAR it is the .xcl file) that tells the linker where to place everything. You can edit this file to customize the environment for your particular needs. Doing that you can reserve a chunk of FRAM space to use for your data storage.

Read the linker user's guide for whichever toolchain you are using.

Irene, you shouldn’t directly pick a location where you store your data. You should tell the linker that you need this space, and the linker will pick the location and relocate all accesses in your code to match it. This way you won’t have problems if your program later changes (code grows etc.)
However, it is not a trivial task.

 On the FR devices, the FRAM can be used for permanent code storage as well as for variable (writable) data. You can simply request a sufficiently large global array and tell the linker to put it into uninitialized data space, so it doesn’t get initialized at power-on (but rather keeps old contents). I don’t know the exact syntax, as I don’t use CCS or IAR, but IIRC it is as easy as putting a #pragma before the array definition. Then simply use it and be sure it won’t conflict with the storage position of your code.
The drawback is that after recompiling the code, the linker may assign a different location. That’s good if your space requirements change, but a new version of the firmware will not be able to access the old data anymore.

Alternatively, you can modify the linker script to reserve a certain area of FRAm for your storage, and tell teh compiler to put it there instead of normal variable space. How to do it depends on the toolchain. And the proper programming of the memory protection unit adds anothe rlevel of complexity. In this case, however, you know that your data is always at the same place and therefore will survive a firmware update (as long as you don't do a mass erase befor writign the new firmware).