MSP430FR5994: How to use FRAM memory instead of RAM 8K

> .TI.persistant and #pragma PERSISTANT

Did you get any warnings from the compiler? I think these are spelled "PERSISTENT" [Ref CCS C Compiler UG (SLAU132Y) Sec 5.11.22].

You may or may not also need to work with the MPU [Build Settings->General->MPU [Tab]].

Make sure you use the default cmd file that has the define of the Persistent as below

make sure to the PERSISTENT like below in the code

#pragma PERSISTENT(flag)

unsigned int flag = 0; 

If I use default .cmd file, then I have to map all other memory sections as well which we are using now. To map those addresses, could you please share some document for mapping. This cmd we are using from last 5 year and product is in market, we need analyze its impact as well.

Do we have other method to use FRAM other then #pragma?

Are you fairly certain your .cmd file doesn't mention the TI.persistent section? My lnk_msp430fr5994.cmd from ccsv7 (2017) does.

In order to make FRAM writable you can (a) disable the MPU, which makes all FRAM writable (most people don't recommend this) or (b) lay out the memory protection yourself, using your .cmd and .map files. Either of these can be done using the MPU tab I mentioned.

As Bruce mentioned make sure the area is writeable and you also try to use the pointer as below

#define T_ADDRESS1 0x5500

  *(unsigned char *) T_ADDRESS1 = 0;

Hi,

What we understood we need move to latest cmd file which available with ccsv8. 

But here default addresses mention in lnk_msp430fr5994.cmd file not matching with datasheet or memory address.

Could you please share relevant document (Memory mapping) having address details.

Just see RAM address only, as per datasheet it should be start from 3BFF and 2BFF, this not mention in .cmd file.

Regards,

Pradeep Lokhande

Data sheet (SLASE54D) Table 9-41 shows FRAM starting at 0x4000. This matches with the ("low") FRAM area in the MEMORY section of the (default) lnk_msp430fr5994.cmd I get from CCSv8. The RAM area is 0x1C00-0x2C00, and the LEA-shared RAM (0x2C00-0x3C00) is called LEARAM. I think you can combine these (if you're not using the LEA), but that doesn't affect FRAM usage.

I don't know whether you need to do anything with your current .cmd file since I don't know what's in it. If it was based on a .cmd file you got from CCS, it's possible you don't need to change anything.

Hello Bruce,

As this is our very old project, we do not want to much changes. But we need to understand in detail before adding new features in this MCU.

I have gone through the memory map defined in datasheet SLASE54D. Here max RAM we can utilize 8KB (Include LEA section).

But in our linker file we have mapped below low FRAM  address to .bss segment. Now CCSv8 considering it as 28K RAM ( 8K RAM + 20K FRAM ). We have verified this in map file as well, here all uninitialized data moves directly to BSS_RAM area. And initialized variable goes into actual RAM. Here we have not used any #pragma statement but using all variable as good as RAM variable.

Linker file snapshot for BSS_RAM area:

Mapped BSS_RAM area to .bss section.

Snapshot of map file where most of variables mapped to BSS_RAM area instead of RAM.

In map file rw data value shown as 6948. And if we define and use large array of 20K here, it also not give any error and data also showing 26K around.

I have attached linker file and map file of our project for your reference.

Could you please confirm, is this allocation is correct. Can we consider it as 28K RAM available for development. As we are not using any #pragma here. Please go through attached linker file and map file of our project.

Regards,

Pradeep Lokhande

This is an unusual usage, which I haven't tried, but I don't see why it wouldn't work.

I don't see your attachments, but my only concern would be with the MPU, which has alignment requirements. Using the Persistent pragma works with the linker (via READ_WRITE_MEMORY and _MPU_ENABLE) to set up the MPU configuration for you. If you're working within that, I expect it would be OK. If not, you might have to manually set up the MPU via the MPU tab.

Are there any surprises when you run it?

MSP430FR5994_Code_Files.zip

Please refer attached file. 

Here look into 20K area of BSS_RAM. We are using it as RAM area in addition to 8K RAM. 

The linker .cmd does a collection of things to support MPU setup, which are absent in your customized .cmd. As a result the MPU tab doesn't really help you, so I think you'll need to configure the MPU directly.

Poking through the library source and the linker file, I came up with this sequence:

int
_system_pre_init(void)
{
    MPUCTL0 = 0xA500;                           // Unlock and disable
    MPUSEGB1 = (unsigned int) (0x9000UL >> 4);  // Seg1/Seg2 border
    MPUSEGB2 = (unsigned int) (0x10000UL >> 4); // Seg2/Seg3 border
    MPUSAM   = (unsigned int) 0x1553;           // Info R, Seg3 RX, Seg2 RX, Seg1 RW
    MPUCTL0  = (unsigned int) (MPUPW | MPUENA); // Enable
    MPUCTL0_H = 0; //protect MPU registers
    return(1);                                  // Proceed with C init
}

I think you'll recognize the 0x9000, for which you can probably define a linker symbol if you want. The 0x10000 is somewhat arbitrary, since segments 2 and 3 have the same access. It also doesn't have to be packaged as _system_pre_init, but that seems convenient and timely. I used this to build a little program using your .cmd file, and I was able to write .data and .bss, but not .text.

Hi Bruce,

What I understood from your reply, we can use .bss area BSS_RAM as a RAM. Is it right?

BSS_RAM 20K + RAM 8K , so we have total 28K for RAM usage. We we look into MPU once this RAM area definition topic is understood correctly.

The short answer is Yes. I've done this in the past, including DMA (I used Persistent, since it was convenient). My "little program" above included writing a single word to each of .data(SRAM), .bss(BSS_RAM), and .text(FRAM/2). The first two succeeded and the third failed (ignored).

I encourage you to try it, to see if there's anything about the method we haven't thought of. In particular, it seems like there's some kind of dynamic (program) loading going on, which I can't really test.

At high CPU speeds you may (or may not) see a very slight performance cost due to NWAITS > 0. 

I think you will not succeed without doing something with the MPU. In your current program, either (a) the MPU is enabled (with default values), and you can't write any FRAM or (b) the MPU is disabled, and you can write to all FRAM (including .text).