Hi,
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.
Hi,
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