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.

MSP430F5335: Cause of reset

Part Number: MSP430F5335


Hi.

MSP430F5335 is reset radomly.

Reading the SYSRSTIV shows the following flags are set:

#define SYSRSTIV_SECYV     (0x000Au)    /* SYSRSTIV : Security violation */

#define SYSRSTIV_SVSL      (0x000Cu)    /* SYSRSTIV : SVSL */

#define SYSRSTIV_SVSH      (0x000Eu)    /* SYSRSTIV : SVSH */

#define SYSRSTIV_SVML_OVP  (0x0010u)    /* SYSRSTIV : SVML_OVP */

#define SYSRSTIV_SVMH_OVP  (0x0012u)    /* SYSRSTIV : SVMH_OVP */

#define SYSRSTIV_DOPOR     (0x0014u)    /* SYSRSTIV : Do POR */

#define SYSRSTIV_WDTTO     (0x0016u)    /* SYSRSTIV : WDT Time out */

#define SYSRSTIV_WDTKEY    (0x0018u)    /* SYSRSTIV : WDTKEY violation */

#define SYSRSTIV_KEYV      (0x001Au)    /* SYSRSTIV : Flash Key violation */

#define SYSRSTIV_FLLUL     (0x001Cu)    /* SYSRSTIV : FLL unlock */

#define SYSRSTIV_PERF      (0x001Eu)    /* SYSRSTIV : peripheral/config area fetch */

#define SYSRSTIV_PMMKEY    (0x0020u)    /* SYSRSTIV : PMMKEY violation */

These flags remain clear:

#define SYSRSTIV_BOR       (0x0002u)    /* SYSRSTIV : BOR */

#define SYSRSTIV_RSTNMI    (0x0004u)    /* SYSRSTIV : RST/NMI */

#define SYSRSTIV_DOBOR     (0x0006u)    /* SYSRSTIV : Do BOR */

#define SYSRSTIV_LPM5WU    (0x0008u)    /* SYSRSTIV : Port LPM5 Wake Up */

What could cause this condition?

BR

Anders

  • Hi again.
    After further investigation we have found that the cause for the reset is:
    SYSRSTIV_KEYV

    This reset seems to be Flash Key Violation:
    #define SYSRSTIV_KEYV (0x001Au) /* SYSRSTIV : Flash Key violation */

    What could cause this?

    BR
    Anders
  • Hi,

    The flag is Flash key violation. You can find the description in the MSP430x5xx and MSP430x6xx Family User's Guide (Rev. P).

    Best Regards,

    Winter Yu

  • Hi Winter.

    The strange thing here, is that the firmware doesnt write to the FCTLx register at all...

    We can see, during testing, that the reset is highly dependent on temperature, the reset occurs quite fast after the temperature is lowered.

    Some boards are also dependent on voltage supply.

    Are there any other sources for a reset like this?

    BR

    Anders

  • Hi Anders,

    You said the reset is highly dependent on temperature and supply voltage. Could you please provide the exactly temperature and supply voltage for testing. For MSP430F5335, if the application requires the performance provided by higher MCLK frequencies,
    software should ensure that VCORE has been raised to a sufficient voltage level before changing MCLK, since failing to supply sufficient voltage to the CPU could produce unpredictable results. So what's your Vcore and system frequency?

    Best Regards,
    Winter Yu
  • Hi Anders,

    You can refer to this app note www.ti.com/lit/pdf/slaa729 especially section 3.2 System Frequency Dependency on Supply Voltage for more details.

    Best Regards,

    Winter Yu

  • Hi Winter.
    Sometimes the resets starts at 3.3V, but not always.
    A new build board runs at 3.6V, and is battery powered, this issue is seen on field returns.
    When temperature drops to around 0C the resets seems to happen more often, meaning its more temperature dependent than supply voltage dependent.
    Frequency of the part is set to 1MHz, and never changes.
    Vcore settings are default, meaning PMMCOREV[1:0] = 0 (default at boot), which should be OK according to figure 5-1 in the datasheet for clock frequencies below 8MHz

    SVS is disabled:
    SVSMHCTL &= ~(SVMHE+SVSHE); // Disable High side SVS
    SVSMLCTL &= ~(SVMLE+SVSLE); // Disable Low side SVS

    This said it doesn't seems like the reset occurs due to flash errors, or power supply issues...


    BR
    Anders

**Attention** This is a public forum