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.

MSP430FR2476: Clock System ISR

Part Number: MSP430FR2476

Hello everyone,

I am currently working on a project using the MSP430FR2xx/4xx and implementing the Clock System fault ISR.

Based on the MSP430FR2xx/4xx Family User's Guide, my understanding of the fault logic is the following:

DCO Fault (DCOFFG): The flag is set when the DCO tap reaches 0 or 511 while the DCO is unlocked. This can occur in two scenarios:

  • Incorrect configuration or temperature drift - the N-multiplier is set too high for the selected DCO range, causing the tap to hit the ceiling (511), or the FLL loses lock and the tap hits the floor (0)
  • XT1 HF crystal failure while used as the FLL reference - when XT1 is operating in HF mode as the FLL reference source, a crystal fault causes no FLLREFCLK signal to be generated. The FLL continues counting down to zero attempting to lock, the DCO tap moves to the lowest position (DCO bits cleared), and DCOFFG is set. This is distinct from XT1 LF mode, where a crystal fault automatically switches FLLREFCLK to REFO instead

XT1 Oscillator Fault (XT1OFFG): If the XT1 oscillator stops, XT1OFFG is set. Each oscillator has a hardware fault counter that resets when a fault occurs and starts counting once the fault condition is removed. The fault flag is cleared only when the counter reaches its maximum value:

  • 8192 cycles in XT1 LF mode
  • 1024 cycles in XT1 HF mode

My planned ISR behavior is as follows:

DCO Fault Handling: If DCOFFG is set and the DCO tap equals 0 or 511, I interpret this as the DCO hitting its adjustment limits due to either a configuration issue, temperature drift, or XT1 HF crystal failure. In this case I plan to trigger a DCO recalibration routine. If the fault persists after several retries, I perform a software POR as a last resort recovery mechanism.

XT1 Fault Handling: If XT1OFFG is set, the ISR will attempt to clear the fault flag and implement a retry loop that repeatedly clears XT1OFFG and checks OFIFG, allowing time for the oscillator hardware counter to reach its maximum count and confirm the oscillator has stabilized. If the fault persists after multiple attempts, additional recovery actions are taken.

My question is: Does this approach align with the intended clock fault handling mechanism for the MSP430FR2xx/4xx devices? Specifically, is it recommended to recalibrate the DCO when the tap reaches its limits, and to use a retry loop to allow the XT1 oscillator's internal fault counter to clear before taking further action?

Any guidance or recommended implementation patterns would be greatly appreciated.

#if defined(__TI_COMPILER_VERSION__) || defined(__IAR_SYSTEMS_ICC__)
#pragma vector=UNMI_VECTOR
__interrupt void UNMI_ISR(void)
#elif defined(__GNUC__)
void __attribute__ ((interrupt(UNMI_VECTOR))) UNMI_ISR (void)
#else
#error Compiler not supported!
#endif
{
    switch(__even_in_range(HWREG16(__MSP430_BASEADDRESS_SYS__ + OFS_SYSUNIV), SYSUNIV__OFIFG))    {

        case SYSUNIV__NONE: //OFFSET 0
            break;
       
        case SYSUNIV__NMIIFG: //OFFSET 2
            break;

        case SYSUNIV__OFIFG:{  //OFFSET 4

            uint8_t csctl7 = HWREG8(CS_BASE + OFS_CSCTL7_L);
            if(csctl7 & DCOFFG) {
               
                HWREG8(CS_BASE + OFS_CSCTL7_L) &= ~DCOFFG;
                HWREG8(SFR_BASE + OFS_SFRIFG1) &= ~OFIFG;
               
                count_DCO_fail++;
               
                if(!(HWREG8(SFR_BASE + OFS_SFRIFG1) & OFIFG)) {
                    count_DCO_fail = 0; // Reset consecutive counter if fixed
                }
               
                if(count_DCO_fail >= 10) {
                    HWREG16(PMM_BASE + OFS_PMMCTL0) = PMMPW | PMMSWPOR; // 10-strike POR
                }
            }

            else if (csctl7 & XT1OFFG){

                if ((HWREG16(CS_BASE + OFS_CSCTL4) & SELMS) == CS_XT1CLK_SELECT){
                    HWREG16(CS_BASE + OFS_CSCTL4) &= ~SELMS;
                    HWREG16(CS_BASE + OFS_CSCTL4) |= CS_REFOCLK_SELECT;
                }
                if ((HWREG16(CS_BASE + OFS_CSCTL4) & SELA) == SELA__XT1CLK){
                    HWREG16(CS_BASE + OFS_CSCTL4) &= ~SELA;
                    HWREG16(CS_BASE + OFS_CSCTL4) |= SELA__REFOCLK;
                }

                HWREG8(CS_BASE + OFS_CSCTL7_L) &= ~XT1OFFG;
                HWREG8(SFR_BASE + OFS_SFRIFG1) &= ~OFIFG;

            }

            break;
        }

        default:
            break;
    }
}
  • Hi Ahlam,

    I think what's your current handing on clock fault make sense. 

    Refer to 3.2.13 of MSP430FR4xx and MSP430FR2xx family user's guide (Rev. I), if software clears the DCOFFG or XT1OFFG fault bits and the fault condition still exists, the fault bits are automatically set again; otherwise, they remain cleared. So your "retry" steps is some attempt to check whether the clock fault is caused by any transient issue, and if the clock could not be recovery (the fault bit is set again) after several time, then some other action needs to do such as POR reset needs to do.  

  • Hi Pengfei Xie,

    Thank you for your reply.

    Do you recommend that I explicitly account for the built-in XT1 oscillator fault counter in my implementation? My understanding from the user guide is that the hardware counter begins counting once the fault condition is removed, and only when the maximum count is reached is the XT1OFFG flag cleared.

    In my ISR, I was planning to repeatedly clear XT1OFFG and check OFIFG in a loop to allow the oscillator time to stabilize and for the internal counter to complete. I was also considering the additional changes I mentioned earlier, such as triggering a DCO recalibration when the DCO tap reaches its limits (0 or 511).

    Would you recommend implementing the logic this way, or is there a more appropriate approach for handling these clock faults in firmware?

    Thank you again for your guidance.

  • Hi Pengfei Xie,

    I have attached my updated Clock System ISR below. I would greatly appreciate it if you could let me know whether this approach aligns with the recommended fault-handling strategy for the MSP430FR2xx/4xx devices, or if there are any improvements you would suggest.

    Thank you again for your guidance.

  • Hi Ahlam,

    It looks fine for me for your current implementation. 

    What I mentioned before is in case of the oscillator is recovery after clear fault flag but then get failure again after a period time, we could monitor the failure times by software to give a stronger recovery action (like POR) after a certain times of failure is monitored.