今天給大家介紹的是改動i.MXRT1xxx里IOMUXC_GPR寄存器保留位可能會造成系統(tǒng)異常。

在群里有一位非?；钴S的朋友，前段時間反映了一個在i.MXRT1062應(yīng)用程序里動態(tài)調(diào)整FlexRAM導(dǎo)致WDOG模塊工作異常的問題。經(jīng)過一番排查，發(fā)現(xiàn)了i.MXRT芯片系統(tǒng)設(shè)計里的一個小秘密，這個秘密警示我們在MCU里應(yīng)盡量遵循謹(jǐn)慎的外設(shè)寄存器賦值法。

這個寄存器謹(jǐn)慎賦值法是什么？這里先賣個關(guān)子，文末會揭秘。今天就將這個問題解決過程還原一下，希望對大家有所啟發(fā)：

一、重配FlexRAM影響WDOG的表象問題

先交待一下問題背景，這個網(wǎng)友是在i.MXRT1062板子上做的測試，使用的是 SDK_EVK-MIMXRT1060oardsevkmimxrt1060driver_exampleswdogiar 例程（XiP），他對工程啟動文件和主函數(shù)改動如下：

intmain(void)
{
wdog_config_tconfig;
BOARD_ConfigMPU();
BOARD_InitPins();
BOARD_BootClockRUN();
BOARD_InitDebugConsole();

PRINTF("
********System Start********
");

//使能WDOG模塊，設(shè)置Timeout時間，不啟用中斷
WDOG_GetDefaultConfig(&config);
//Timeout value is(0xF+1)/2=8 sec.
config.timeoutValue=0xFU;
WDOG_Init(DEMO_WDOG_BASE,&config);
PRINTF("---wdog Init done---
");

while(1)
{
//故意不喂狗，讓W(xué)DOG超時復(fù)位系統(tǒng)
//WDOG_Refresh(DEMO_WDOG_BASE);
PRINTF("
WDOG has be refreshed!");

/*Delay.*/
delay(SystemCoreClock);
}
}

他在啟動文件 startup_MIMXRT1062.s 里將默認(rèn)128KB ITCM、128KB DTCM、256KB OCRAM的FlexRAM分配調(diào)整成了256KB DTCM、256KB OCRAM（關(guān)于FlexRAM基本知識，這種FlexRAM動態(tài)調(diào)整方式僅適用XiP工程。最終運行結(jié)果里看，應(yīng)用程序似乎僅運行了一次，沒有像預(yù)想得那樣重復(fù)啟動執(zhí)行。

如果在 startup_MIMXRT1062.s 里將重配FlexRAM代碼去掉，這個WDOG例程是可以正常工作的，串口助手里可以看到循環(huán)打印，所以這很容易讓人推斷出FlexRAM重配功能導(dǎo)致WDOG模塊工作異常了。

二、找到程序異常的根本原因

由于這個WDOG例程并不是完全功能異常，至少首次打印是有的，說明重配FlexRAM并沒有對程序堆棧運存等造成實質(zhì)影響，啟動文件里那段重配FlexRAM代碼本身沒有邏輯問題。而打印輸出在WDOG超時時間到了之后就沒有了，看起來WDOG模塊應(yīng)該是正常產(chǎn)生了軟復(fù)位。

為了最小化代碼去定位問題，我們將這個網(wǎng)友WDOG例程主函數(shù)修改如下，去掉WDOG相關(guān)代碼，直接用 NVIC_SystemReset() 代替。運行后發(fā)現(xiàn)，仍然僅有一次打印，這個實驗的意義是那段重配FlexRAM代碼會導(dǎo)致軟復(fù)位后程序沒法再次運行，而跟具體WDOG模塊無關(guān)。

intmain(void)
{
BOARD_ConfigMPU();
BOARD_InitPins();
BOARD_BootClockRUN();
BOARD_InitDebugConsole();

PRINTF("
********System Start********
");

while(1)
{
NVIC_SystemReset();
}
}

我們現(xiàn)在將焦點放回到重配FlexRAM那段匯編代碼本身，代碼很簡單，就是將i.MXRT芯片內(nèi)部的IOMUXC_GPR->GPR17（基址0x400ac044）和IOMUXC_GPR->GPR16（基址0x400ac040）分別整體賦值為0x5555aaaa和0x00000007，單純從寄存器有效功能位定義上來看，這樣操作是沒問題的。

  LDR R0,=0x400AC044
  LDR R1,=0x5555aaaa
  STR R1,[R0]
  LDR R0,=0x400AC040
  LDR R1,=0x00000007
  STR R1,[R0]

翻看手冊里關(guān)于IOMUXC_GPR->GPR17和IOMUXC_GPR->GPR16寄存器的位定義，發(fā)現(xiàn)IOMUXC_GPR->GPR16寄存器中有很多bit是保留位，并且其中bit21保留位默認(rèn)值是1，與其他保留位默認(rèn)值0不一樣。顯然 IOMUXC_GPR->GPR16 = 0x00000007 這樣的賦值語句會將其bit21誤清零，并且IOMUXC_GPR寄存器在軟復(fù)位后也不會改變其值 。

難道問題是由IOMUXC_GPR->GPR16[21]保留位被誤清零導(dǎo)致的？死馬當(dāng)活馬醫(yī)吧，我們修改一下重配FlexRAM代碼如下（兩種方式都行），將IOMUXC_GPR->GPR16[21]保持為默認(rèn)1。

運行后發(fā)現(xiàn)，異常問題解決了，串口助手里可以看到循環(huán)打印?，F(xiàn)在我們知道了IOMUXC_GPR寄存器即使是保留位也不要輕易當(dāng)用戶標(biāo)志位使用，更不要輕易改變其默認(rèn)值，因為SoC占用了這些位，具體用途未詳述。由此可以推測IOMUXC_GPR->GPR16[21]位跟系統(tǒng)啟動有關(guān)，并且其值的設(shè)置是在軟復(fù)位后才生效的。

#ifdef FLEXRAM_CFG_STANDARD
  LDR R0,=0x400AC044
  MOV32 R1,0x5555aaaa
  STR R1,[R0]
  LDR R0,=0x400AC040
  LDR R1,[R0]
  ORR R1,R1,#4
  STR R1,[R0]
#else
  LDR R0,=0x400AC044
  LDR R1,=0x5555aaaa
  STR R1,[R0]
  LDR R0,=0x400AC040
  LDR R1,=0x00200007
  STR R1,[R0]
#endif

三、MCU外設(shè)寄存器謹(jǐn)慎賦值法

現(xiàn)在為大家揭秘文章開頭賣的關(guān)子，到底什么是謹(jǐn)慎的外設(shè)寄存器賦值法？

其實可以從芯片頭文件定義里去學(xué)，假設(shè)我們有一個模塊叫PERIPH，模塊內(nèi)部有一個名為REG的寄存器，這個寄存器中有功能位FUNC（單bit或者多bit），芯片頭文件中通常定義如下：

typedefstruct{
__IOuint32_tREG;
}PERIPH_Type;

#definePERIPH_REG_FUNC_MASK(0x4U)//或者(0xCU)
#definePERIPH_REG_FUNC_SHIFT(2U)
#definePERIPH_REG_FUNC(x)(((uint32_t)(((uint32_t)(x))<

#definePERIPH_BASE(0x400AC000u)
#definePERIPH((PERIPH_Type*)PERIPH_BASE)

//如果PERIPH->REG[FUNC]是單bit
PERIPH->REG|=PERIPH_REG_FUNC_MASK;
PERIPH->REG&=~PERIPH_REG_FUNC_MASK;
//如果PERIPH->REG[FUNC]是多bit
PERIPH->REG=(PERIPH->REG&(~PERIPH_REG_FUNC_MASK))|PERIPH_REG_FUNC(value);