msp430fr6989 write in FRAM

Hi Alessandro,

In CCS, by default the MPU (Memory Protection Unit) is enabled with partitions set by the compiler and linker cmd file. This memory protection unit restricts access to the FRAM and by default with this code you have posted, it is going to set all of the FRAM to read + execute access only - no write access. The MPU is a good thing - because FRAM is so easy to write to, you need something to help protect your code from being corrupted if for example you write off the end of an array or something similar. So this is why we have the MPU.

The problem in your case, is that the compiler doesn't really know that you are writing to FRAM with this code and doesn't know to set the MPU accordingly. Also, the way your code is written could be a problem if your program was larger and so it happened to have code at 0xD000, because you would be overwriting your code - the linker handles the code placement and doesn't know that you are writing to 0xD000.

The recommended way to place variables in FRAM, is to use the PERSISTENT pragma in CCS. See the FRAM best practices guide www.ti.com/lit/pdf/slaa628 section 3.4.1 and the compiler guide www.ti.com/lit/pdf/slau132 . There are also some other forum posts on a similar topic.

Basically, what your code should instead do, is to declare a variable for the data you want to store and use the persistent pragma, like this:

#pragma PERSISTENT(FRAM_data)
unsigned long FRAM_data = 0;

Then instead of using that FRAM_write_ptr to do your writes, simply use this like any other variable:

	FRAM_data = data;

If you want to store a whole bunch of data, like in a logging application, simply declare an array instead, like this:

#pragma PERSISTENT(FRAM_arr)
unsigned long FRAM_arr[1000] = 0;

And then use it like any other array:

FRAM_arr[i]=data;

or could still use a pointer here now just like you could with any array.

In CCS, when you debug, you can view FRAM_data in the expressions window, and you'll see where the compiler chose to place it (likely 0x4400), and you'll be able to see that writes are now successful, because the compiler and linker knew to adjust the MPU settings to allow for you to write to this part of FRAM.

The advantages of this method are a few:

1. The linker knows how much space to allocate for your FRAM data that you are going to want to write, so it will leave enough space and not put any code there that could accidentally get corrupted otherwise

2. The compiler and linker will automatically adjust the MPU settings to allow write access to your variable while still protecting your code, without you having to do anything custom yourself with the MPU settings

3. You can use the variable just like any other variable that was in RAM without even having to think about the fact that it's in FRAM - it doesn't need extra special treatment like flash where you'd have to have some write function. The only thing to remember is that the variable will retain its value through a power cycle/reset because it is in FRAM, only being re-init to the default value when you load code. If you want to truly have it reset every time like a RAM variable, you can init it in your main code somewhere before you use it, but otherwise you will have access to the persistent data you've logged there through power cycles.

I hope that this helps address your needs. This doesn't put the FRAM variables at a user-defined address, but that usually isn't needed since you can just access these like regular variables - if there is some reason you need to define the specific address for the placement, please let us know why and we can help you work towards a solution for that. But this method with the simple pragma PERSISTENT is the way we recommend for most people and seems to be working fine for most use-cases that I've encountered.

Regards,

Katie

Hi Alessandro,

The MSP430FR6989 has a built-in bootloader in ROM for this purpose. However this loader only supports UART (or I2C). If you really need SPI, then you'll have to implement a main-memory bootloader. We have an application note MSPBoot www.ti.com/.../slaa600 just for this purpose. In that case, you are going to be modifying and controlling your linker file, and in this case yes you may want to control placement yourself then by further customizing your linker file. You would set aside a portion of your FRAM in your linker file (e.g. in the linker file, set the Memory FRAM to start at a later address and subtract from its length, then add a line to make an area like MY_FRAM defined to actually start at 0x4400 the beginning of FRAM and take up the space you just carved out of FRAM). This would be to leave a space for your logging data in your application project. Then in the SECTIONS part of the linker file, have the .persistent section of the linker file be placed in this area that you've set aside, and also in that case manually control your MPU settings so that they are set correctly for your custom setup.

Currently, MSPBoot doesn't have an example for MSP430FR6989, rather it has an example for one of the older FRAM parts MSP430FR5739. It also does not yet support 20-bit address space, but I do know others have modified it for this before if you search the forum (and we can also try to help here on e2e if you have questions as you work on it). Please know that we actually are currently working on an update for MSPBoot that will address this gap, including an MSP430FR6989 example with 20-bit support, but I do not know any release date for this yet - it could be some time.

Regards,
Katie