MSP430F67641A: MSP430F67641A Three phase meter resets on load insertion

Part Number: MSP430F67641A

Hello

We developed a Three phase meter based on MSP430F67641A
The difference with reference design is an isolated power supply was used to provide MCU power.

We have a big issue with load insertions and resets.

When there is a significant different in current (for example a relè activating a 250W load), we observe resets of the MCU.

I tried to filter condcted noise caused by these spikes but any solution seems inefective.
Is any known issue regarding noises conducted on any pin that force device to reset or to latch up?

We are not willing to share schematic here(yes privately with a FAE)

Thanks 

  • Hi Massimo,

    Are you able to read the SYSRSTIV register to get what caused the reset?

    If there is enough noise on the circuit you could cause an accidental reset, so it is good to see from this register where the trigger point is coming from - the VDD input or the NRST pin.

    Regards,
    Luke

  • Hello

    Was 04h = RST/NMI (BOR)

    So i tried to activate internall pull up and change pin function to NMI.

    Seems the device won't reset anymore. But I will test further.

    I let you know

  • UPDATE

    “The device now operates for hours without resetting, but occasionally it freezes and the watchdog triggers (SYSRSTIV = 16h). On one of the occasions when it reset due to the watchdog, it failed to restart afterwards: it remained stuck in the reset condition and I had to remove the power supply to recover it.

  • Are you placing any conditionals on the RST NMI which could cause the device to not exit the NMI?

    If you have an external pull-up resistor you can reduce the value to provide a stronger pull-up and also increase the decoupling cap to help reduce the impacts of the switching noise. The larger cap value can cause issues with flashing the device at higher speeds due to the RC.

    If you can get to the case where the watchdog does not recover the device, I would recommend connecting to the device and checking where in the code the device is. If there is the RST NMI and its not getting cleared properly, then the watchdog might be doing a weaker reset (PUC) and also not clearing the condition which is causing the device to hang.

  • Hello, there is no NMI ISR in the code. There's no ISR to "get stuck in" or fail to exit from.

    First i noticed that the device froze after a WDT reset, and it was resettable with reset PIN, so de device had never reached the main(), since first instructions in main are

    WDTCTL = WDTPW | WDTSSEL__ACLK | WDTIS__512K;
    SFRRPCR = SYSRSTRE | SYSRSTUP | SYSNMI;

    I thought the problem was Vcore, since was on level one and i tried to run at 19.8Mhz

    So now I set Vcore at level 3 (1.93V)

    The device has run smoothly until now, and i thought i solved my issure.

    After few hours this morning i found the device was frozen like the WDT started but not completed the reset, in fact this was the situation

    Reset pin was not available(no possible to reset by pulling down reset pin)
    Vcore was 1.9V (level 3)

    I assume the WDT since all LED pins was in reset condition.

    Was like it tried to reset but it was unable to complete the reset.

    It froze and hanged on reset.
    Device was not in debug at that moment. Was under test and It ran smoothly for hours


  • Hi Massimo,

    Are these conditions still when load is applied, or does this happen even under no load conditions? Do you have varistors or any high-transient protection on the input stage for the votlage?

    Regards,

    Luke

  • This happens only when a large load is switched in. I observed a common‑mode transient with a 5 V peak and a base frequency around 15 MHz (plus harmonics). During no‑load or steady‑load conditions, no resets occur.

    The issue appears when a large load (2 kW) is enabled through a relay. If the relay closes when the mains sine wave is near its peak, the circuit is hit by a transient similar to a step response. This obviously generates noise that reaches the circuit and couples into the logic. The noise is likely coupled unevenly through the ground plane and the PCB traces, creating a differential‑mode effect on the MCU pins. It is very hard to observe directly, because the oscilloscope earth affects the measurement; I was only able to detect the noise on the AFE using a LISN with 50‑ohm resistors.

    Here is what I tried, unsuccessfully:

    I tried using the internal low‑frequency oscillator for the watchdog timer. It barely mitigated the problem, but after a few hours the device froze again.

    I am honestly surprised that the watchdog does not reset the MCU properly, leaving it stuck in a half‑reset condition.

    What I mean is that the MCU appears to be in a reset state, with GPIOs in their reset condition, but it does not start up again.

    At startup, I first configure the watchdog to use the internal oscillator, then I disable the RESET pin, and then I increase VCORE to level 3 step by step.

    By the way, the reset cause is now always “watchdog timer elapsed time”, and it works correctly almost every time.

    To test the solution, I used a test bench that switches a 2 kW load on and off every second. After several hours, with multiple resets and recoveries (the reset cause was always watchdog timeout, meaning the device froze several times), it eventually froze after a reset.




  • I was wondering. By reference design VDSYS is connected to AUX3. Shall I try to connect to DVCC instead?

  • New event: It has frozen in the middle of a cycle (board led was enabled), but WDT didn't reset the circuit after time elapsed.

    I expected WTD to reset the MCU eventually.

    WDTCTL = WDTPW | WDTSSEL__VLO | WDTIS__512K;   // WDT , VLOCLK  (~10kHz)
    SFRRPCR = SYSRSTRE | SYSRSTUP | SYSNMI; //rest is NMI
    SetVCore(PMMCOREV_3); //routine that set PMMCOREV at level 3 step by step)

    //clock config

        UCSCTL3 = SELREF__REFOCLK;                                  // FLLRef = internal REFOCLK (~32.768kHz)
        UCSCTL4 = SELA__REFOCLK | SELS__DCOCLKDIV | SELM__DCOCLK;   // ACLK = REFOCLK, SMCLK = DCO/n, MCLK = DCO
        __bis_SR_register(SCG0);
        UCSCTL0 = 0x0000;
        UCSCTL1 = DCORSEL_6;
        UCSCTL2 = FLLD__1 | 600;
        __bic_SR_register(SCG0);



  • Do you have a ferrite bead on the power connection to the device? I think you have the correct observation, and the cause is due to an electrical event caused by these load transients. I don't have your schematic, and I think it's going to be a bit of a challenge to solve this with software considering the internal watchdog reset is hanging. I would focus more on ways to suppress the EMI or transients from impacting the MCU

**Attention** This is a public forum