MSP430FR5969 Incompatibility

[Andres Gomez]

Hello,

I'm trying to run this code on a MSP430FR5969 eval board (with an lcd), the only difference is that it has 2K of SRAM. However, the code hangs when it tries to restore the stack. What is weird is that when I copy ony the first few hundred bytes of SRAM to the FRAM, it works fine (I'm placing a few int vars in the bottom of the sram, and they're restored without problems). But when I go to restore the stack, the PC jumps off to a weird address (I noticed while I did some debugging). As you mention, I'm not using memcpy since it alters the stack, do you have any idea what could be causing it to run off?

P.S.
Restoring only the SFR also works fine.

[Joe]

What address does it jump to on the RET exiting the Restore()? Can you paste your code here or somewhere online? I just got a 5969 dev board so I'll take a look at it in the next few days.

[Andres Gomez]

It don't think it's reaching the ret instruction. It's going crazy in the middle of the copy loop...

I'm using code composer studio, I've posted the CSS project (seem easier) here:
https://github.com/andres625/msp430fr5969_hibernate

My goal is to have the sram counter in the stack, rather than as a global, which is my temporary fix to make it work. In the define section, you can see some SRAM values commented out, these make it crash.

I should point out that in the linker script, I created a FRAM_STACK region (2KB) to back up the SRAM stack when I press the Switch2. I also have a different region, FRAM_DATA, where I keep my fram variables seperate (both are of the no_init type).

Thanks for your help!

[Joe]

Andres,

I spent a little time getting the hibernate running on an exp430fr5969 board I had. When I backed up all of the SRAM and initialized it after the hardware init after reset I didn't have any problems.

Here are the listings:
-main.c: https://gist.github.com/jotux/2f7d51acf920e22f0dcf
-lnk_msp430fr5969.cmd: https://gist.github.com/jotux/b8d7edee3e634da20353

As you can see, I added a fram_data segment to memory, after the main fram segment.

FRAM_DATA               : origin = 0xEF80, length = 0x1000
....
.fram_data  : {} > FRAM_DATA,type = NOINIT

I defined the backup locations, and backed up the entire SRAM.

#define RAM_LOC        0x1C00
#define RAM_SIZE       0x800
#define SFR_LOC        0x0200
#define SFR_SIZE       0x013F

But my backup locations were a little different from yours.

#pragma DATA_SECTION(f_from,".fram_data")
volatile uint8_t* f_from;
#pragma DATA_SECTION(f_to,".fram_data")
volatile uint8_t* f_to;
#pragma DATA_SECTION(f_mem_cnt,".fram_data")
volatile size_t   f_mem_cnt;
#pragma DATA_SECTION(f_asleep,".fram_data")
volatile uint8_t  f_asleep;
#pragma DATA_SECTION(f_ram_backup,".fram_data")
volatile uint8_t  f_ram_backup[RAM_SIZE];
#pragma DATA_SECTION(f_sfr_backup,".fram_data")
volatile uint8_t  f_sfr_backup[SFR_SIZE];

Looking at your code I'm not really sure what the problem is, but I can speculate. First, hardware initialization code does set values in the SFR but a lot of hardware, like clocks, have settling times. So you can't just write the values into the SFR and assume the hardware is correct. For that reason you have to set up the hardware on reset/POR before you restore the stack.

Also I suspect, in general, you want to back up all of the SRAM and not just the stack so you restore local variables, the heap, and the stack all at once. If you just do the stack, the bottom 256-or-so-bytes, you're not going to get the local variables (like your counter) restored.