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.

MSP430F6779A: About UCS Module Fail-Safe Operation

Part Number: MSP430F6779A

Our circuit board uses an XT1 crystal (32768 Hz) that not stable in the first 600 ms after the DVCC is applied.

Configuration:


ACLK: XT1CLK
SMCLK:DCOCLKDIV With FLL XT1CLK reference clock
MCLK:DCOCLKDIV With FLL XT1CLK reference clock

Clock status:
OFFG = 1
XT1LFOFFG = 1

So during this time within 600 ms (the crystal not stable) the Fail-Safe Operation will do automatically, right?

Does the fail-safe clock always work correctly (100 %)?

Shall we manually configure the FLL reference clock to REFOCLK during this time (start up) and then switch to the XT1 after the crystal stable (600 ms)?

  • Hi Tink

    May I know the reason of XT1 crystal not stable 600 ms after the DVCC is applied?

    from the UG description,

    a crystal fault automatically causes the FLL reference source, FLLREFCLK, to be sourced by the REFO.

  • Hi,

    for 600 milliseconds is characteristic of the crystal oscillator circuit. After supplying voltage from 0 V to 3.3 V

    I also have some experiments on clock failure states with some conditions of DVCC and AUXVCC1 below.

    1) When connecting and disconnecting the DVCC 0 to 3.3 V power supply, connect AUXVCC1 to 3.3 C continuously.
    Result: No oscillator failure detected.

    2) When connecting and disconnecting the DVCC 0 to 3.3 V power supply, connect AUXVCC1 to 1.4 V and below.
    Result: Oscillator failure detected.

    Why is an oscillator failure detected (OFFG = 1
    XT1LFOFFG = 1) with AUXVCC1 voltage 1.4 and below?


    From all of the above my discussion was about suspected cause (clock source failure) of the problem. Where I found the MCU get stuck (the device not start) in the actual use field. But it cannot be reproduced in a laboratory.

    This cannot use the debugger to debug where the code is stuck. (becuase the debugger reset the program counter)

    Symptoms of the bug were just checked with the H/W pin
    (device does not start).
    Vcore pin = 1.42 V (core level 0 AM)
    Reset pin = 3.3 V

  • some related issues i discussed.

    e2e.ti.com/.../5051888

  • Hi,

    I have another question about code below?

    int _system_pre_init(void)
    {
        /* Insert your low-level initializations here */
        __disable_interrupt();
        WDTCTL = WDTPW+WDTHOLD;
    
        // Clear RTCHOLD Bit after reset
        RTCCTL0_H = RTCKEY_H;     // unlock
        RTCCTL1 &= ~RTCHOLD;      // release RTC
        RTCCTL0_H = 0x00;         // lock
        
    }

    Is it correct to clear RTC hold bit in system_pre_init?

    Are there any problems/risks when the RTC hold bit is clear in system_pre_init (DVCC and crystal are not yet stable, related to MCU stuck or not)?

  • Hi Tink

    These is _disable_interrupt () at the beginning of the code.

    I think all interrupt is disable here.

    I don't have idea how to release RTC here because the interrupt is disable

    Thanks

**Attention** This is a public forum