This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MSP430FR5964: FRAM corruption on power cycle

Part Number: MSP430FR5964
Other Parts Discussed in Thread: UNIFLASH, MSP-FET

We are encountering an issue that appears to be parts of the MSP430FR5964 FRAM being corrupted when power is cycled to the device.

The linker memory segments are defined as follows:
MEMORY {
  TINYRAM          : ORIGIN = 0xA, LENGTH = 0x0016
  BSL              : ORIGIN = 0x1000, LENGTH = 0x0800
  RAM              : ORIGIN = 0x1C00, LENGTH = 0x2000
  INFOMEM          : ORIGIN = 0x1800, LENGTH = 0x0200
  INFOD            : ORIGIN = 0x1800, LENGTH = 0x0080
  INFOC            : ORIGIN = 0x1880, LENGTH = 0x0080
  INFOB            : ORIGIN = 0x1900, LENGTH = 0x0080
  INFOA            : ORIGIN = 0x1980, LENGTH = 0x0080
  ROM (rx)         : ORIGIN = 0x4000, LENGTH = 0xBF80          /* END=0xFF7F, size 49024 */
  HIROM (rx)       : ORIGIN = 0x00010000, LENGTH = 0x00032FFF  /* END=0x42FFF, size 208895 */
  HIRAM (rw)       : ORIGIN = 0x00042FFF, LENGTH = 0x1000      /* END=0x43FFF, size 4096 */
  JTAGSIGNATURE    : ORIGIN = 0xFF80, LENGTH = 0x0004
  BSLSIGNATURE     : ORIGIN = 0xFF84, LENGTH = 0x0004
  IPESIGNATURE     : ORIGIN = 0xFF88, LENGTH = 0x0008
  ISRVECTORS (r)   : ORIGIN = 0xFFB4, LENGTH = 0x004C
}

Text and read only data sections are going into both ROM and HIROM (these are the lower and upper FRAM segments).

After flashing the MSP430 over JTAG using an MSP-FET, power is cycled to the board.  The debugger is reattached and the memory in FRAM and upper FRAM are read out using TI's UniFlash tool, and compared with the binary that was flashed onto the microcontroller.  We see that a handful of bytes in the read-only sections have been changed (eg .rodata, .lower.text, .upper.text).

The program enables the memory protection unit (MPU) on boot by defining a function in section .crt_0001, which gets called immediately after __crt0_start and before __crt0_init_bss.  The MPU is configured to make ROM and HIROM segments read and execute only.  If the MPU detects an illegal memory operation then it fires an NMI, which turns on a red LED.  As the MPU is enabled I don't see how a memory bug in the code could be modifying protected parts of the FRAM.

What we observe is that after flashing the program operates normally but after power cycling some FRAM is corrupted.  Different bytes are corrupted each time in different sections of lower and upper FRAM.  If the program hits a corrupted instruction then (depending on the contents of the corrupted section), an illegal instruction or memory violation occurs and the MPU is triggered, leading to the red LED turning on.  Even if the red LED doesn't turn on, I can still read out the microntroller's memory and see that some bytes have changed on power cycle, even if the bytes haven't caused an observable code malfunction.  I've tried flashing, letting it run, then reading out the memory before the power cycle.  It only ever gets corrupted after the power cycle.

The MSP430 is powered from 3.3V and all DVCC and AVCC pins are connected together.  I cannot find anything in the forums, datasheets, or errata that give any clues about what might be causing this.  We have recreated it on two different boards.

  • Hi Sam

    Thanks for your information and I know you can re-produce this issue. May I know what is your application? Could you please contact MSP product line quality or application team offline through the TI field team? we will support you through the mail. Thanks!