Fram data/code management confusion

You probably choose to use c.

IAR and CCS both try to do every thing "automatically" for you. You normally do not need to manage the segments of code & data. You do not need to specify where your buffer of 2 KB is. They will do it "automatically" for you. You do not need to where is "boot". It "automatically" start to run your code.

If you want to know how IAR and CCS do it, then you have to dig into the documentations of them. Search TI E2E or the WWW. All kinds of people have all kinds of problems with them. There are an over abundance of information and misinformation alike.

I choose to use assembly.

I put code, data or garbage at precisely the address I want to. I do not need any "boot". I put the address of the beginning of my code in the Reset Vector and the hardware will start from there.

Hi

old_cow_yellow said:

you have to dig into the documentations of them ... I choose to use assembly.

Although that is still no escape from a thorough study of the documentation!

;-)

It is the Linker that allocates memory. It is directed by a Link Command File. The Link Command File in IAR for MSP430FR5739 says code, constant, etc. must be less than 15.5 KB, and variables, stack, etc. must be less than 1 KB. If either one does not fit, Liker will generate error msg and will not generate object file.

Hi

The problem is, that on 'normal' MSPs, the segmentation is fixed. Ther eis RAM and there is flash. Code that is intended to run in ram must be stored in flash and copied to ram on startup, as the ram is volatile. The size of ram is known, the size of flash is known, the two won't overlap.

On FRAM, the borders are fading. The linker doesn't know how to handle this.

Normally, the linker starts placing code from the beginning of flash up. Then it adds the init data for variables. Ram again is allocated form the beginning for vriables. And the unused part is considered stack space form top of ram down.

Now on FRAM, the 'beginning of flash' is unknown. There is only one huge area that can be both. The linker algorithms are unable to handle this. A completely new linker would be necessary. e.g. a two-pass linker which determines code zize in the first run, then adjusts the border between data and program space, and then does a second run to link everything in place. However, nobody bothered to do it just for one signel FRAM chip in the whole MSP world. Understandable.
The solution was to assume a fixed segmentation of FRAM and let the linekr do it the usual way. The MPU is programmed for a fixed configuration ewven if it could be way more flexible.

What you can do is to change the linker script that contains this fixed segmentation, and to alter the init code that configures the MPU. Of course the changes in the linker script must match the MPU programming.

Hi

The linker doesn't care for defines. Besides command line options and maybe a few special symbols, it follow sits script.

But as I said, the linker fills the code bottom-up. So as long as the code, the constants etc don't fill the FRAM further than 0xD000, this code will work. If the code or the constants grow larger, it will break.

assaf laufer said:

in other words, if i want to always use a specific section of the FRAM as my non volatile buffer, is this enough ?

The FRAW_Write function will simply write where you tell it to write, overwriting previous content, may it be code, constants or variable init values.

Hi,