MSP430FR5994: RAM data changes spontaneously while executing the MSP430 program

Being (mostly) a software guy, I tend to suspect software first. Array overrun (including runaway DMA) or stack overflow can have indirect effects which might show up first as random byte-spray. Often the values of the errant bytes provide a clue.

Thank you for your reply. But in the actual case, I don't suppose that it is a software case, because it only occurs during the login phase of the modem in the internet. At that time, there are no additional informations on the data or interrupt lines going to the MSP430. The MSP430 works alone, without any additional activity (only the "while(1)" loop in the LPM).

During that modem network login phase, the modem has rapidly changing power consumption from few uA to 1A (short power pulses). I can't measure it precisely enough with the scope, but I suppose, that it might be a very short  disturbance (or similar) in the Vcc power, that cause these RAM errors. When these spikes enters the MSP430 at any pin (Vcc, UART or a port), the RAM of the MSP430 receives a randomly impulse to change the values. What do you think about that hypothesis?

A SRAM cell is very stable and it takes a lot to upset it. Drops in Vcc sufficient to do that will trigger a brown out reset. But if you have the recommended capacitors on each Vcc pin, then rapid changes are unlikely.

Software is the most likely culprit. But if the modem has wildly changing power requirements, it would require careful design of the power supply to keep that from leaking into the power rails. A dedicated voltage regulator and careful design of the ground system might be required in extreme cases.

Thank you for your reply. A dedicated voltage regulator could not be a solution in our case, because, as I mentioned above, the RAM errors also occurs if only an interrupt line is connected to a port of the MSP430 (2 separated voltage regulators for the modem and the MSP430). On our PCB, we have a 100nF capacitor on each Vcc pin of the MSP430. 

To test the influence of the software, I wrote a very small program, that only toggles an output port. A single global variable (defined in a "test.h" file and used in the "main.c" file) is also changed randomly during the initialisation of the modem, but without occurring a reset of the MSP430. Without the modem on the same power line, the MSP430 didn't have problems at all, with the same global variable. I found out, that it mostly (eventually only) concerns the global variables. So I think, if it is a software purpose, it might not be a RAM overflow, but something else, what I don't know a this time. Has someone an idea for further checks to do?

Could we try to place small additional capacitors on the interrupt and UART lines? Would it be possible? Has someone tested it in the past?

Furthermore, I found out, that if I declared the global variables as "volatile" with the attribute " __attribute__ ((section(".TI.noinit")));", they don't change randomly any more.

Could this be an indication, to found the origin of our problem? Are the variables in the "noinit" section saved differently from the normal variables in the RAM? Thank you for your help.

.noinit is allocated separately, i.e. at different addresses from .bss/.data. You could compare the .map files to see if there's a clue there.

This still seems to point to software (bad pointer?), but as I mentioned I (almost) always blame software first.

Noinit also means that the variables are not initialized after a reset. 

Are you sure the MSP430 is not resetting due to the power noise from the modem?  Are the "corrupted" variables possibly just reverting back to their originally initialized state and then running from there?

You said you made a simple test program and saw the issue again only when the modem is running.  Could you share that simple test program here? 

Thanks,

JD  

Thank you for your replies.

My test code looks like that (see below). The long wait time (before the while loop) helps me to detect an eventual reset of the MSP430. In the normal code, I could read it out by the register. No reset occurs here. After a certain time, the "if (term_reply[1]==0x45)" test became negative, and the LED remains ON or OFF all the time. If it where a real full reset, the reinitialisation in the example code (term_reply[1]=0x45;) would restart the code, but this doesn't take place.

Furthermore, I found out that, when the modem and the MSP430 are only connected together with Vcc, it works well. When I now connect an other data line in between (TX of the modem, or an interrupt line to the MSP430), the MSP430 RAM falls down and the "if (term_reply[1]==0x45)" code is always false.

I tested to make a galvanical separation of the TX modem and the RX MSP430. In that case, the MSP430 works well again. So I suppose, that it is something that enters a port of the MSP430, that disturbs his work. Has someone noticed a similar effect in the past?

------main.c--------------------------------------------------------------------------------------------------------------------------------

#include <msp430.h>
#include <test.h>

void initPorts (void);

unsigned char term_reply[TERM_BUFSIZE];

int main(void)
{
    WDTCTL = WDTPW | WDTHOLD;    // stop watchdog timer
    initPorts();
    PJOUT = 0;
    PJSEL0 = BIT4 | BIT5;
    PJDIR = 0xFFFF;
    PM5CTL0 &= ~LOCKLPM5;
    P8OUT ^= 0x02;   //Modem goes ON
    int i;

    term_reply[1]=0x45;

    P6OUT ^= 0x20;   //LED ON (long wait time)
    for (i=0;i<30000;i++){WDTCTL = WDT_ARST_250;}
    for (i=0;i<30000;i++){WDTCTL = WDT_ARST_250;}
    for (i=0;i<30000;i++){WDTCTL = WDT_ARST_250;}
    for (i=0;i<30000;i++){WDTCTL = WDT_ARST_250;}
    for (i=0;i<30000;i++){WDTCTL = WDT_ARST_250;}
    for (i=0;i<30000;i++){WDTCTL = WDT_ARST_250;}
    for (i=0;i<30000;i++){WDTCTL = WDT_ARST_250;}
    for (i=0;i<30000;i++){WDTCTL = WDT_ARST_250;}
    for (i=0;i<30000;i++){WDTCTL = WDT_ARST_250;}
    for (i=0;i<30000;i++){WDTCTL = WDT_ARST_250;}

    while(1)
       {for (i=0;i<30000;i++){WDTCTL = WDT_ARST_250;}   //Very simple wait Timer
       if (term_reply[1]==0x45){P6OUT ^= 0x20;}   //Toggle LED
    }
}

------test.h--------------------------------------------------------------------------------------------------------------------------------

#define TERM_BUFSIZE        (255)

--------------------------------------------------------------------------------------------------------------------------------------