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

;摘取自 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 值都不会改变。

然后按照串行 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功能可轻松配置指定外设》），痞子衡实测是有效的。

翻看i.MXRT1050 参考手册 System Boot 章节，IOMUXC_GPR寄存器地址空间也确实在有效的 DCD 设置范围。

END

更多恩智浦AI-IoT市场和产品信息，邀您同时关注“NXP客栈”微信公众号

NXP客栈

恩智浦致力于打造安全的连接和基础设施解决方案，为智慧生活保驾护航。

长按二维码，关注我们

恩智浦MCU加油站

这是由恩智浦官方运营的公众号，着重为您推荐恩智浦MCU的产品信息、开发技巧、教程文档、培训课程等内容。

长按二维码，关注我们