關(guān)于MSP430F449時鐘

前幾周使用MSP430F449做產(chǎn)品，因為之前成功地使用過MSP430F149做過東西，心想449也是一個模子出來的換湯不換藥，遂成竹在胸，殊不知，險些栽了跟頭，就在這個多時鐘源的時鐘模塊上。

449和149的時鐘模塊的最大區(qū)別在于449的時鐘包含了可編程FLL模塊，打開449的頭文件，連寄存器的名字都和149完全不一樣，一切均以“FLL”開頭。少頃，但見其內(nèi)容大同小異，遂把以前的寫的149的時鐘初始化代碼中的寄存器改了名號，直接用在了449上。但是馬上就出現(xiàn)了問題：在測試IFG1中的時鐘失效標志位OFIFG之時，會不定期地出現(xiàn)OFIFG始終不復位的情況，程序就這樣在這里止步不前（OFIFG置位表示至少有一個時鐘源實效，如果置之不理，強行運行下面的代碼的話，CPU有可能會強制使用DCO作為MCLK時鐘源，這樣就會使定時操作出現(xiàn)錯誤）。我的板子上接了32K的LFXT和8M的XT2，遂懷疑匹配負載電容有問題，因為低速晶體振蕩器LFXT提供了內(nèi)置的匹配電容。但是不管如何搭配內(nèi)部與外部電容，始終不得解。

這之后的某日，我借出恭之便仔細研讀了449文檔里的時鐘模塊相關(guān)內(nèi)容，發(fā)現(xiàn)OFIFG竟然是時鐘模塊控制寄存器FLL_CTL0中XT1OF、XT2OF、LFOF、DCOF這4的狀態(tài)位相或的結(jié)果，頓時靈光一現(xiàn)，遂編寫代碼將相關(guān)狀態(tài)位于幾個管腳上LED關(guān)聯(lián)，察看其狀態(tài)，結(jié)果令我大吃一驚：我一直認為有重大嫌疑的LFXT和XT并沒有任何問題，LFOF與XT2OF都會在上電后瞬間復位，而我一直覺得絕對不會有問題的DCOF卻一直置位！

接下來，我仔細查閱了文檔，原來在SCFI1中有5位設置了DCO tap數(shù)值，這個數(shù)值若這個數(shù)值設置的過高或過低都會使DCOF置位，從而使OFIFG置位，而PUC后這五位都是復位的，就是說，DCO tap值在PUC后被設置為最低值0，所以有可能會使DCOF置位。

上網(wǎng)搜了一下，其實這個DCO還是蠻強大的，雖說其頻率會受到溫度與電壓的影響，通過調(diào)整也能到達相當?shù)木?。因為我已?jīng)把LFXT和XT都備全了，這個應用也不需要節(jié)電，所以沒有再太多的研究這個DCO到底怎么用，在程序里做了個計數(shù)，把DCO tap所有的可能數(shù)值都試了一下，以保證時鐘初始化的順利。

我最后時鐘初始化代碼如下，以供和我遇到同樣問題的朋友參考。

/******************************************************/
//初始化系統(tǒng)時鐘
void SysClkInit(void)
{
unsigned int i;
unsigned char DCOtap = 0x01;

SCFQCTL |= SCFQ_M;
FLL_CTL0 &= XCAP18PF;
_BIS_SR(OSCOFF);
FLL_CTL1 &= ~XT2OFF;

IFG1 &= ~OFIFG; // Clear oscillator fault flag

do
{
IFG1 &= ~OFIFG;
for (i = 5000; i; i--); // Delay
SCFI1 |= ((DCOtap++) & 0x0f) << 3;
} while (IFG1 & OFIFG); // Test osc fault flag
FLL_CTL1 = (SELM1 + SELS); // Select SMCLK source as XT2CLK
return;
}
/******************************************************/

這段代碼已經(jīng)經(jīng)過反復測試，再也沒有遇到時鐘初始化通不過的情況了。