Part Number: MSP430F5438A
Other Parts Discussed in Thread: MSP430WARE,
Hi Experts!
Background:
My customer is having around 1% fallout where his MSP430 application will stall, like the oscillator is not transitioning.
For a small percentage of boards in the field the main application, stops soon after the Main Applications configuration of the clocks.
I am still trying to determine exactly where, but the current draw is small and static.
A scope probe shows that the 25mhz clock is correctly oscillating.
The fault can be duplicated by rapid cycling of power to the board, right around the operational trip point of the micro.
Here is the kicker: On successive clean power-ups the board will continue to fail right after the second set of clock initializations.
The fault can be cleared by rapid cycling of power to the board, after which it will start normally.
Code:
The firmware starts with a Boot Strap Section which verifies the main code before doing a blind jump to the main code.
It has the following Clock initialization code( which is pretty much consistent with TI examples ):
---------------- BSL ---------------------
SetVCore(3);
P5SEL |= BIT2+BIT3; // Port select XT2
UCSCTL6 &= ~XT2OFF; // Enable XT2
// set drive strength [01] for 12mhz
UCSCTL6 &= ~(XT2DRIVE1); // turn off drive bit 1
UCSCTL6 |= XT2DRIVE0 ; // turn on drive bit 0
// set drive strength [00] for 32khz
UCSCTL6 &= ~(XT1DRIVE1); // turn off drive bit 1
UCSCTL6 &= ~(XT1DRIVE0); // turn off drive bit 1
// Set up XT1
P7SEL |= BIT0+BIT1; // Select XT1
UCSCTL6 &= ~(XT1OFF); // XT1 On
// Loop until XT1,XT2 & DCO stabilizes - in this case loop until XT2 settles
do
{
UCSCTL7 &= ~(XT2OFFG + XT1LFOFFG + XT1HFOFFG + DCOFFG);
// Clear XT2,XT1,DCO fault flags
SFRIFG1 &= ~OFIFG; // Clear fault flags
} while (SFRIFG1&OFIFG); // Test oscillator fault flag
UCSCTL4 = 0X0055; //Aclk= Xt1, SMclk = Xt2, Mclk = XT2clk
UCSCTL1 |= DISMOD ; // turn off modulation
{ after doing a checksum check on main application memory it jumps to Main Application }
---------------------- Main Application ------------------------------------
{ Where it goes through a similar clock start up process }
{ This redundancy was done because the nature of the BSL doesn’t lend itself to emulation during debugging}
SetVCore(3);
P5SEL |= BIT2+BIT3; // Port select XT2
UCSCTL6 &= ~XT2OFF; // Enable XT2
// set drive strength [01] for 12mhz
UCSCTL6 &= ~(XT2DRIVE1); // turn off drive bit 1
UCSCTL6 |= XT2DRIVE0 ; // turn on drive bit 0
// set drive strength [00] for 32khz
UCSCTL6 &= ~(XT1DRIVE1); // turn off drive bit 1
UCSCTL6 &= ~(XT1DRIVE0); // turn off drive bit 1
// Set up XT1
P7SEL |= BIT0+BIT1; // Select XT1
UCSCTL6 &= ~(XT1OFF); // XT1 On
// Loop until XT1,XT2 & DCO stabilizes - in this case loop until XT2 settles
do
{
UCSCTL7 &= ~(XT2OFFG + XT1LFOFFG + XT1HFOFFG + DCOFFG);
// Clear XT2,XT1,DCO fault flags
SFRIFG1 &= ~OFIFG; // Clear fault flags
}while (SFRIFG1&OFIFG); // Test oscillator fault flag
UCSCTL4 = 0X0055; //Aclk= Xt1, SMclk = Xt2, Mclk = XT2clk
UCSCTL1 |= DISMOD ; // turn off modulation
This is just a duplication of code.
Questions:
- Is it okay to SetVcore(3) twice?
- The drive strength was set incorrectly for a 25MHz clock which was ultimately used in assembly.
- Even though the clock apprears to oscillate normally, is the internal clocking of the MSP affected?
- Generally speaking, is it OK to manipulte the UCS registers twice?
Thanks!
Reed
