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.
Dear TI team,
We are developing a product based on TI CC430F6137. Below is a snapshot of the device initialization routine which enables XT1 CLK that source from a 32.768KHZ watch crystal. In addition, the XT1_CLK is used as a reference signal to PLL/DCO and generate MCLK.
During the course of stepping through the initialization routine, we occasionally encountered a situation where MCU is trapped in a do-while loop (BOLD font) , because DCOFFG flag always set to 1, regardless of the fact that it is cleared in the loop. This situation happens once in a while when we rapidly switch on/off power to CC430F6137 for multiple times in a role. As soon as the device enters this state, resetting the device through system reset pin doesn't help as the MCU keeps on being trapped in the do-while loop. The only way to resolve the issue is to recycle the power to the MCU in a normal manner. Would you please review our initialization code and give us advice for any improvement that can be implemented to resolve the issue we experienced? Thank you.
Best regards,
Peter
MCU Clock Initialization routine
{
UCSCTL6 &= ~XCAP_3; //Clear XCAP value
UCSCTL6 |= XCAP_1; //Set XCAP value to 6pf
P5SEL |= (BIT0 | BIT1); /* set P5.0 & P5.1 for external source of XT1 */
__delay_cycles(375000);
UCSCTL3 &= ~SELREF_7; /* Set DCO FLL reference = XT1 */
UCSCTL4 |= SELA_2; /* Set ACLK = REFO */
__bis_SR_register(SCG0); /* Disable the FLL control loop */
UCSCTL0 = 0x0000; /* Set lowest possible DCOx, MODx */
UCSCTL1 = DCORSEL_5; /* Select DCO range 24MHz operation */
UCSCTL2 = FLLD_1 + 499; /* (499 + 1) * 32768 = 16384000Hz */
__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.
* 32 x 32 x 16 MHz / 32,768 Hz = 500000 = MCLK cycles for DCO to settle
*/
__delay_cycles(500000); /* delay cycle is updated according to formula */
/* Loop until XT1,XT2 & DCO fault flag is cleared */
do
{
UCSCTL7 &= ~(XT2OFFG + XT1LFOFFG + DCOFFG) /* Clear XT2,XT1,DCO fault flags */
SFRIFG1 &= ~OFIFG; /* Clear fault flags */
}while (SFRIFG1&OFIFG); /* Test oscillator fault flag */
}
Hi hoi,
Please modify this code to test again:
UCSCTL6 |= XCAP_1; //Set XCAP value to 6pf
to
UCSCTL6 |= XCAP_3; //Set XCAP value to 12pf
some specific data as your reference:
And you also can test our code example in your hardware board:
http://dev.ti.com/tirex/explore/node?node=ACdT6Qy5BPEWKIAAMWv5DA__IOGqZri__LATEST
Best Regards
Johnson
Hi Hoi,
What is the failure rate of this issue? Is it necessarily or occasionally?
Could you test this code example in your board, select REFCLK as FLL reference clock, this code be able to check the external crystal is normal or not.
http://dev.ti.com/tirex/explore/node?node=AB0osRaTm6.mtlCdclUUvw__IOGqZri__LATEST
By the way, Is it convenient for you to grab the values of the following UCS module registers when this problem occurs?
Best Regards
Johnson
Hi,
How about your issue?
I haven’t heard from you for six days, so I’m assuming you were able to resolve your issue. If this isn’t the case, please click the "This did NOT resolve my issue" button and reply to this thread with more information. If this thread locks, please click the "Ask a related question" button and in the new thread describe the current status of your issue and any additional details you may have to assist us in helping to solve your issues.
Best Regards
Johnson
Hi,
Congratulations, if you have any question later, please create a post to discuss directly in the E2E community.
Best Regards
Johnson
**Attention** This is a public forum