借助i.MXRT10xx系列INIT_VTOR功能缩短程序热重启时间-电子发烧友网

最近痞子衡写了篇文章《i.MXRT从Serial NAND启动时间测量》，这篇文章详细测试了不同长度的 Non-XIP 程序在不同 NAND 访问速度下由 BootROM 加载启动所需要的时间，比如 240KB 的程序在 60MHz NAND 的访问速度下启动时间接近 30ms，这个启动时间对于有些响应时间敏感的应用（比如汽车电子）来说还是比较长的。

对于Non-XIP 程序，经过冷启动后，其程序体本身已经被加载进芯片内部 SRAM 了，除非发生 POR，否则 SRAM 中的程序会一直保持着。假设程序在恶劣的电磁环境中运行，代码里虽然包含异常复位的处理，但是每次程序复位启动时间还是和冷启动时间一样长（每次都需要 BootROM 搬移加载），有点难以接受。那么对于这种热启动的情况，程序启动时间能够缩短吗？答案是可以的，今天痞子衡就介绍下 i.MXRT 上的 INIT_VTOR 特性：

备注1：本文主角是i.MXRT1050，但内容也基本适用其它i.MXRT10xx系列。
备注2：同样的测试在i.MXRT1160/1170下无效，因为CM7_INIT_VTOR所在的IOMUXC_LPSR_GPR->GPR26在软复位下不能保持。

INIT_VTOR功能简介

在介绍INIT_VTOR 功能之前，大家首先要对 ARM Cortex-M 内核的中断向量表偏移寄存器 SCB->VTOR 功能有所了解，具体可以看痞子衡的旧文《Cortex-M中断向量表原理及其重定向方法》。

简单来说，芯片上电启动后内核都是从 SCB->VTOR 指向的地址处获取程序中断向量表里的第二个向量即所谓的复位函数Reset_Handler。有了复位函数，就找到了程序入口。

;摘取自 startup_MIMXRT1052.s


__vector_table
        DCD     sfe(CSTACK)
        DCD     Reset_Handler


        DCD     NMI_Handler
        DCD     HardFault_Handler
        DCD     MemManage_Handler
        DCD     BusFault_Handler
        DCD     UsageFault_Handler
        ...

对于i.MXRT1050，我们知道芯片上电复位都是执行 BootROM 代码，BootROM 中断向量表固定放在了 0x0020_0000 地址处。那么这个 0x0020_0000 地址是怎么被赋给 SCB->VTOR 寄存器的呢？这就引出了本文主角 IOMUXC_GPR->GPR16[32:7] - CM7_INIT_VTOR 位，这 25bits 的 CM7_INIT_VTOR 值每次复位都会被芯片系统自动加载进 SCB->VTOR[32:7] 中，其默认值即对应 BootROM 中断向量表地址。

正如痞子衡旧文《妙用i.MXRT1xxx里SystemReset不复位的GPR寄存器》提及的那样，IOMUXC_GPR 寄存器仅在 POR 复位或者整体重新上电时才会被置位，这就意味着我们在应用程序中只需要设置一次 CM7_INIT_VTOR 值，其后不管发生多少次类似NVIC_SystemReset() 的复位，CM7_INIT_VTOR 值都不会改变。

使用INIT_VTOR缩短程序热重启有了上一节的理论基础，我们来做个实验。痞子衡找了一块MIMXRT1050-EVK12（Rev.A）板卡，将其启动设备换成串行 NAND 启动（电阻切换到使能 U33，并将 U33 替换成华邦 W25N01GV）。

然后按照串行 NAND 启动时间测试方法那样修改SDK_2_13_0_EVKB-IMXRT1050oardsevkbimxrt1050demo_appsled_blinkyiar 例程（debug build，即代码在 ITCM 运行，注意修改链接文件中的 m_interrupts_start = 0x00002000），并在SystemInit() 函数里调用如下测试函数，根据是否设置 IOMUXC_GPR->GPR16 寄存器编译出两个不同镜像文件（直接编辑 bin 文件将其均填充至 120KB）。

void set_led_gpio(void)
{
  CLOCK_EnableClock(kCLOCK_Iomuxc);
  gpio_pin_config_t USER_LED_config = {
      .direction = kGPIO_DigitalOutput,
      .outputLogic = 0U,
      .interruptMode = kGPIO_NoIntmode
  };
  GPIO_PinInit(GPIO1, 9U, &USER_LED_config);
  IOMUXC_SetPinMux(IOMUXC_GPIO_AD_B0_09_GPIO1_IO09, 0U); 
  IOMUXC_SetPinConfig(IOMUXC_GPIO_AD_B0_09_GPIO1_IO09, 0x10B0U); 


  SystemCoreClockUpdate();
  GPIO_PinWrite(GPIO1, 9U, 0U);
  SDK_DelayAtLeastUs(5000, SystemCoreClock);
  // 根据是否设置 CM7_INIT_VTOR 分别编译两个不同镜像文件
  // 设置 CM7_INIT_VTOR 指向地址 0x00002000，即用户应用程序中断向量表
  IOMUXC_GPR->GPR16 = (IOMUXC_GPR->GPR16 & (~IOMUXC_GPR_GPR16_CM7_INIT_VTOR_MASK)) | IOMUXC_GPR_GPR16_CM7_INIT_VTOR(0x2000 >> 7);
  NVIC_SystemReset();
  while (1);
}

然后借助 MCUBootUtility 工具将这两个不同镜像文件下载进串行 NAND flash，并测试相应启动时间。这里 Flash 运行速度就选择 60MHz：

下面是不设置 IOMUXC_GPR->GPR16 的程序启动时间测试结果，无论是一开始的POR 冷启动还是后面 NVIC_SystemReset() 引起的热启动，启动时间都需要约 18.66ms：

下面是设置了 IOMUXC_GPR->GPR16 指向 0x2000 之后的程序启动时间测试结果，只有一开始的 POR 冷启动时间是 18.66ms，后面 NVIC_SystemReset() 引起的热启动时间仅需要约 5.26ms。

上述实验结果证明，设置 IOMUXC_GPR->GPR16 指向应用程序中断向量表之后确实能缩短程序热启动时间。有朋友可能会疑问，设置了从 ITCM 直接热启动后为何还是有 5.26ms 的启动时间？这其实主要是从进入应用程序 Reset_Handler 到执行到测试 GPIO 拉低时的代码所消耗的时间，并且需要注意的是由 BootROM 加载执行的程序默认是在 ROM 配置后的 396MHz 主频下执行的（主频够快，测试代码消耗时间可以忽略不计），而直接复位从ITCM 里执行的程序是在默认主频 12MHz 下执行的（主频较慢，测试代码消耗时间不得不计）。

最后再提一下，除了直接在应用程序里设置 IOMUXC_GPR->GPR16 之外，也可以借助 BootROM 的 DCD 功能来设置，同样可以借助 MCUBootUtility 直接完成（详细步骤可参考《利用i.MXRT1xxx系列ROM集成的DCD功能可轻松配置指定外设》），痞子衡实测是有效的。