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

在群里有一位非常活躍的朋友，前段時間反映了一個在i.MXRT1062應用程序里動態調整FlexRAM導致WDOG模塊工作異常的問題。經過一番排查，發現了i.MXRT芯片系統設計里的一個小秘密，這個秘密警示我們在MCU里應盡量遵循謹慎的外設寄存器賦值法。

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

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

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

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

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

//使能WDOG模塊，設置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)
{
//故意不喂狗，讓WDOG超時復位系統
//WDOG_Refresh(DEMO_WDOG_BASE);
PRINTF("
WDOG has be refreshed!");

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

他在啟動文件 startup_MIMXRT1062.s 里將默認128KB ITCM、128KB DTCM、256KB OCRAM的FlexRAM分配調整成了256KB DTCM、256KB OCRAM（關于FlexRAM基本知識，這種FlexRAM動態調整方式僅適用XiP工程。最終運行結果里看，應用程序似乎僅運行了一次，沒有像預想得那樣重復啟動執行。

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

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

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

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

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

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

while(1)
{
NVIC_SystemReset();
}
}

我們現在將焦點放回到重配FlexRAM那段匯編代碼本身，代碼很簡單，就是將i.MXRT芯片內部的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]

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

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

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

#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外設寄存器謹慎賦值法

現在為大家揭秘文章開頭賣的關子，到底什么是謹慎的外設寄存器賦值法？

其實可以從芯片頭文件定義里去學，假設我們有一個模塊叫PERIPH，模塊內部有一個名為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);