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.

EVM430-F6736: DCOFFG is Setting continuously.

Part Number: EVM430-F6736

Hi,

We had recently purchased the EVM and when we powered it up, nothing got displayed in the LCD. We doubted the EVM to be not programmed and hence loaded the project(as in SLAA517E). The board got programmed, the LCD didn't come up but other parts of the program were working(checked through debugger). We doubted the LCD and wrote a simple program to check if the LCD and that worked(the LCD came up). We debugged a bit in the application code mentioned in SLAU517e and observed the following:
1. If we comment LFXT_Start() called in system_setup() function then everything seems to work normal(including the LCD).
2. The DCO fault flag is always set when the program is running even if we clear it.(validated through debugger)
It would be helpful if anyone can provide some insight.
Thanks & Regards
Shahul
  • Hi Shahul,

    It is possible that your LFXT crystal (Q1) is defective and not oscillating properly, causing the fault flag loop to fail. Can you confirm in the debugger whether the XT1LFOFFG bit is set? You can also try probing the XIN/XOUT pins or replacing the crystal.

    Regards,
    Ryan
  • Hi Ryan Brown,

    Thanks for your response. I just rechecked it and XT1LFOFFG  not set. This does not seem to crystal problem as we are using brand new EVM430-F6736. So, what could be the reason for setting DCOFFG?.

    Thanks & Regards

    Shahul

  • Hi Shahul,

    The DCO fault flag is set when the DCO tap moves to the lowest position (DCO are cleared) or if the N-multiplier value is set too high for the selected DCO frequency range (resulting in the DCO tap moving to the highest position). In summary, if the if DCO bits in UCSCTL0 register value equals {0} or {31}. DCOFFG remains set until cleared by the user but will be automatically set if a fault condition remains. Is the MSP430 device being adequately powered? At least 2.4 V must be supplied for a PMMCOREVx level of 3. Do you have any other EVM430-F6736 boards to test?

    Regards,
    Ryan
  • Hi Ryan,

    Thank for your input. As you can see in the debugger output UCSCTL0 value does not equal to  {0} or {31}. We have also verified DVCC is getting sufficient(3.3v) voltage. As of now, we don't  have another EVM430-6736 board but we are not sure how having another EVM430 could help because the issue seems to be with the DCO and not with external crystal.

    Thanks & Regards

    Shahul

  • Hello Shahul,

    It looks like you're using code from SLAA517 (I could find SLAA517E but unfortunately not SLAU517E). I think I've seen this issue before, and basically it's caused by the watchdog timer (WDT) timing out right before the delay for the DCO setting time is finished.

    For a quick test, you can disable the WDT, and it should work correctly. If you'd like to keep the WDT running in your application code, you could try kicking (or resetting) the WDT. In your the 'emeter-setup.c' file, can you add the following line of code before the "SetVCore(3)" function inside the "system_setup()" function?

    kick_watchdog();    /* Set the watchdog timer to exactly 1s */

    Please let me know if this fixes your issue. As general feedback, make sure the AUX1, AUX2, and AUX3 jumpers are populated on the EVM430-F6736.

    Regards,

    James

    MSP Customer Applications

  • Hello James,

    Thanks for your valuable input. After connecting all AUX jumpers, LCD is started working properly without commenting LFXT_Start(XT1DRIVE_3); in  system_setup(void) function with slaa517e code but DCOFFG is still not clearing after adding kick_watchdog(); as you suggested.

    Thanks & Regards

    Shahul

  • Hello Shahul,

    I'm glad that the jumpers fixed the LCD issue.

    Regarding the DCOFFG issue, I think I was confusing it with a different issue where the DCO setup never occurred due to the WDT resetting the device. Looking in the 'emeter-setup.c' file from the SLAA517E code, I don't see where the DCOFFG is polled and cleared before and after configuring the DCO. Here's the code that you'll want to add.

    while (SFRIFG1 & OFIFG)
        {
            /* Check OFIFG fault flag */
            UCSCTL7 &= ~(DCOFFG | XT1LFOFFG | XT2OFFG); /* Clear OSC fault flags */
            SFRIFG1 &= ~OFIFG;                          /* Clear OFIFG fault flag */
        }

    To know where this code should be added, here's more code from a similar project where I polled and cleared the DCOFFG (and others) before setting the DCO and then after the DCO settles.

        SetVCore(3);
        UCSCTL5 |= DIVS__1;
        UCSCTL4 = SELM__DCOCLK | SELS__DCOCLK | SELA__XT1CLK;     /* 25MHz MCLK, 25MHz SMCLK, 32KHz ACLK */
        
        __bis_SR_register(SCG0);                        /* Disable the FLL control loop */
        UCSCTL6 = (UCSCTL6 | XT1DRIVE_3);               /* Highest drive setting for XT1 startup */
        while (SFRIFG1 & OFIFG)
        {
            /* Check OFIFG fault flag */
            UCSCTL7 &= ~(DCOFFG | XT1LFOFFG | XT2OFFG); /* Clear OSC fault flags */
            SFRIFG1 &= ~OFIFG;                          /* Clear OFIFG fault flag */
        }
        UCSCTL6 = (UCSCTL6 & ~(XT1DRIVE_3));            /* Reduce drive to something weaker */
    
        UCSCTL0 = 0;
        UCSCTL1 = DCORSEL_6;                            /* Set RSELx for DCO = 25MHz */
        UCSCTL2 = FLLD_2 | (192 - 1);                   /* Set DCO Multiplier for 25MHz */
                                                        /* Set FLL to 4*192*32768 => 25165824Hz */
        __bic_SR_register(SCG0);                        /* Enable the FLL control loop */       
        
        // Worst-case settling time for the DCO when the DCO range bits have been
        // changed is n x 32 x 32 x f_MCLK / f_FLL_reference. See UCS chapter in 5xx
        // UG for optimization. Here, n = 1, since FLLREFDIV is 1.
        // 32 x 32 x 25 MHz / 32,768 Hz ~ 780k MCLK cycles for DCO to settle    
        __delay_cycles(782000);     
      
        // Loop until XT1, XT2 & DCO stabilizes
        while (SFRIFG1 & OFIFG)
        {
            /* Check OFIFG fault flag */
            UCSCTL7 &= ~(DCOFFG | XT1LFOFFG | XT2OFFG); /* Clear OSC fault flags */
            SFRIFG1 &= ~OFIFG;                          /* Clear OFIFG fault flag */
        }

    I confirmed that the DCOFFG is cleared after setting up the DCO. I hope this helps!

    Regards,

    James

    MSP Customer Applications

  • Hello James,

    Thanks for your input and it resolved our issue.

    Thanks & Regards

    Shahul

**Attention** This is a public forum