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.

msp430f6779 resets as temperature rises

Other Parts Discussed in Thread: MSP430F6779, CC1101

Hello,
We use msp430f6779 for a 3-phase meter application, based on application note SLAA577.
For some time we identified a critical problem, which is a showstopper on our side - the circuit resets without any reason.
We tried to isolate the problem, and it is related to temperature. We've conducted the following experiment using a temperature chamber:
3 different units powered with only Vcc (no AC inputs, Vcc directly connected from DC power supply) and placed in the temperature chamber showed resets above a certain temperature (45-55 C), getting worse as temperature climbed.

1. Someone suggested that maybe the temperature safeguards going off too soon. Could it be the case? Is someone familiar with such an issue?
2. We found an Errata (PMM18) which refers to over-voltage protection – which causes software resets – going off too soon, and it gets worse at higher temperatures. How can I test if this is indeed my case? And if it is my case - how can I workaround it? Does it have a fix in some version of the silicon (different mask / HW revision)?

Thanks,
Lior.

  • The circuit won't reset without a reason. It's just that you didn't identify the reason yet.
    Raising temperature changes the capacitance of capacitors. It may even break up bad soldering points (and close them again when temperature drops), but this is unlikely with three units.
    Rising temperature also affects the power consumption, it affects the frequency of the DCO and even REFO. Are you sure you configure the device properly (proper PMMCOREV level for the operating speed you picked)?
    After start, your software can read SYSRSTIV register. It gives you the reason of all resets since emptying it last time. (each reason once and in order of priority, not order of appearance). You can see whether it was a vacant memory fetch (which usually indicates a CPU failure due to overclocking or stack overflow), a voltage supervisor reset (must be programmed properly to be useful beyond brownout detection), a brownout, a watchdog reset etc.
    What about the VCORE capacitor? Is it really 470nF, even at raised temperature? Check the typical tolerances. Nothing but this cap should be connected to VCORE.
    The overvoltage protection function is not enabled by default. And PMM18 applies only if it is explicitly enabled, your system voltage is >=3.2V and you're coming out of LPM2..4
    How clean is your power supply?
  • Thank you Jens-Michael,

    I've followed your advise, and saw that the SYSRSTIV often indicates of a watchdog reset.

    I've disabled the watchdog, and then saw that the system gets stuck (don't know exactly where, since I have a debugger issues), but I've suspected the CC1101 RF module, which I use the SPI bus to communicate with.

    I am not sure why, but for some reason,when the temperature goes up over 45 Celsius, something is wrong with the SPI communication with the CC1101. I proved that by removing all communication actions, and the system continued to perform flawlessly.

    Does temperature has affect over the SPI bus or CC1101 RF module? Have anyone encountered such a phenomena?

    Thanks,

    Lior.

  • I'm not aware of any issues with SPI and temperature. It might be that temperature alters SPI clock speed and timing so much that the CC1101 is unable to properly read the data anymore. This is especially true if you have the wrong polarity/phase setting. If both settings are wrong at the same time, the communication often seems to work, but with very narrow timing tolerance regarding signal edges. Changes due to temperature can break the seemingly correct communication.
    Also, temperature may affect the upper speed limits. If you're working at the upper edge, rising temperature may make the MSP exceed the CC1101 maximum SPI clock speed.

    The fact that communication hangs, does also indicates a flaw in your SP code. It seems to assume always correct response and hangs if it doesn't happen instead of reporting an error. (I guess, an error handler would have saved you some debugging time). Well, it's no critical flaw, as in your case, the slave is known and should be always there or the whole system is broken. :)
  • Thank you very much for the extensive explanation!

    For now, I've reduced the SPI clock speed to 1 MHz, and now everything works flawlessly.

    However, I would really like to know more as for your assumption.

    Could you please elaborate the "wrong polarity/phase setting"?

  • SPI bus operation has two parameters (besides the maximum allowed clock frequency): Polarity and phase. Polarity defines whether the clock is considered active when the signal is low or when it is high. Phase defines whether the data is taken when the clock becomes active or when it becomes inactive. if master and slave expect a different polarity and phase, communication may still work, as line capacitance and signal timing often open a small window where still the correct data is sampled. If only one is set wrong, communication will always fail. Of course, ideally both should match :)
    It should be noted that Motorola and TI differ in their meaning what 'polarity = 1' means. So better check the timing diagrams to be sure.
    In the majority of cases, using CKPL=1 and CKPH=0 is the right choice, but there are many exceptions.

**Attention** This is a public forum