在前一篇文章 《i.MX RT1060/1010上串行NOR Flash冗余程序启动设计》里，我详细介绍了i.MX RT10xx上的冗余程序启动设计，本质上这就是个双备份程序启动， NORFlash里存两份一样的image，物理地址靠前的image 0启动失效就继续启动后面的image 1，多一层保障。

i.MX RT1170是区别于i.MX RT10xx的第二代架构，性能/功能更加强大，其在继承 i.MX RT10xx冗余程序启动的基础上，新增了双程序可交替启动设计，今天我们就来聊聊这个话题：

一、初识双程序可交替启动

与i.MX RT10xx一样，这里要聊的还是在一片挂载在FlexSPI上的串行NOR Flash里做冗余/双程序设计，就是下图中的image L和image H，不涉及LPSPI接口Flash B里的image 2。

先说跟i.MX RT10xx上一样的冗余程序启动流程，i.MX RT1170上电先启动物理地址靠前的image L，如果image L被破坏了，则继续启动image H。

什么是双程序可交替启动呢？简单说就是物理地址靠前的image L并不总是上电首先启动的image，在i.MX RT1170上新增了如下原型的image version启动头（在固定偏移 0x600 处），芯片上电 BootROM 会尝试判断两个 image L/H 里的 version 头版本，高版本的 image 优先被启动。这种设计方便了 OTA 升级。

Note: 当image L/H中均不含有效version启动头时（img_ver 等于 0xFFFFFFFF，或者高低16bit不符合取反关系），双程序可交替启动特性就不生效，此时等效于冗余程序启动，image L 永远被优先启动。

typedef struct
{
    uint16_t version;     // 版本值
    uint16_t inversion;   // version值的取反（~version）
} img_ver_t;

二、回顾冗余程序启动

在测试双程序可交替启动新特性之前，还是先过一下冗余程序启动。按照文章《i.MX RT1060/1010上串行NOR Flash冗余程序启动设计》第2节里一模一样的方法，在恩智浦官方MIMXRT1170-EVK开发板上做测试，这个板子FlexSPI1上挂了两片Flash，默认连接的16MB QuadSPI Flash，还有一片 64MB OctalFlash（需要做板子改动才能使能）。

在 i.MX RT1170 fuse 里关于冗余程序启动的使能位定义与i.MX RT10xx上差不多，只不过 fuse 地址从 0x6E0 换到了0xC80。还是跟之前测试一样借助MCUBootUtility工具将 FLEXSPI_NOR_SEC_IMAGE_OFFSET 烧录为 0x10，xSPI_FLASH_IMAGE_SIZE 保持默认 0，即第二份 image 偏移地址在 Flash 0x400000（4MB）处，最大 image 长度也是4MB。

继续用\SDK_2.11.0_MIMXRT1170-EVK\boards\evkmimxrt1170\demo_apps\led_blinky\cm7\iar\flexspi_nor_debug例程生成两个稍微不一样的 image，闪灯间隔时间一个是200ms（image L - iled_blinky_cm7_delay200ms.bin），另一个是 2s（image H - iled_blinky_cm7_delay2s.bin）。在 MCUBootUtility 工具主界面下使用 All-In-One 操作将 image L 下载进 Flash（baseaddress 设为 0x30000400），使用通用编程器界面 Write 操作将 image H 也下载进 Flash（Start 设为0x400400）。

现在Flash 里有了两份 image，当第一份 image 启动失败后，i.MX RT1170 BootROM 不是立刻去执行下一份 image ，还是那个取巧的方法，在一个软复位不置位的寄存器里（SRC_GPR10）标记当前状态，然后调用 NVIC_SystemReset() 重新进入 BootROM 执行。不过此时标记位从 GPR10[30] 换到了 GPR10[27:26]，虽然是 2bit 状态，但设值 1/2/3 等效于设值 1，因为对于串行 NOR Flash 最多就是两份 image。这时候如果你想挂 J-Link 改写 SRC_GPR10 去做快速验证恐怕无法如愿，原因请看 《i.MX RT1170上用J-Link连接复位后PC总是停在0x223104》。

所以在i.MX RT1170上只能老老实实做破坏 image 完整性的动作来验证冗余程序启动，经实测其效果与i.MX RT10xx 是完全一致的。

三、实测双程序可交替启动

现在我们开始实测双程序可交替启动，主要的工作量就是为 image L 和 image H 添加 version 启动头，并且将它们分别下载进 Flash。因为我们想验证物理地址靠后的 image H 比 image L 优先启动（冗余程序启动做不到这点），所以需要将 image H 的 version 头版本设高一点。

3.1 为 image 添加version 启动头

还是在\SDK_2.11.0_MIMXRT1170-EVK\boards\evkmimxrt1170\demo_apps\led_blinky\cm7\iar\flexspi_nor_debug例程基础上，首先在工程链接文件 MIMXRT1176xxxxx_cm7_flexspi_nor.icf 添加如下语句，指定 .img_ver 段的位置。

define symbol m_boot_img_ver_start           = 0x30000600;

place at address mem: m_boot_img_ver_start { section .img_ver };

然后在工程随便一个源文件里添加如下常量 s_bt_img_l_ver 定义，这个 image 闪灯间隔时间是 200ms（image L -iled_blinky_cm7_delay200ms_ver0.bin），版本是 0x0000（注意编译链接工程时为防止 s_bt_img_l_ver 被优化，可以在工程选项 Linker / Input /Keep symbols 里将其添加进去）。

const img_ver_t s_bt_img_l_ver @ ".img_ver" = {
    .version = 0x0000,
    .inversion = ~0x0000,
};

同样的工程，再生成另一个闪灯间隔时间为 2s（image H -iled_blinky_cm7_delay2s_ver1.bin） 的 image 时使用如下常量s_bt_img_h_ver 定义，版本是 0x0001。

const img_ver_t s_bt_img_h_ver @ ".img_ver" = {
    .version = 0x0001,
    .inversion = ~0x0001,
};

当然如果你嫌上述方法繁琐，也可以直接在最终 image binary 文件上做修改（注意 offset 位置一定要找对，i.MX RT1170 SDK XIP binary 文件起始数据对应 Flash 偏移是 0x400，因此文件中 0x200 处才对应 Flash 偏移 0x600）：

3.2 下载含 version 头的image 进 Flash

现在需要借助 MCUBootUtility 工具的通用编程器功能分别将两个含 version 头的 image L/H 下载进 Flash。这里需要注意的是此时 image L 无法再通过主界面 All-In-One 操作来下载了，因为工具 v3.4 版本及以下没有对 version 启动头做识别处理，因此会丢掉 version 头数据（这个考虑会在 v4.0 之后加入支持）。

两个 image下载完成，一切工作就结束了，这时候你调整芯片启动模式到 2'b10 - Flash boot，给板卡重新上电，应该可以看到 image H 正在执行。

3.3 BootROM中判断version的逻辑

BootROM中关于 version 启动头是否有效以及版本高低判断逻辑其实是有一点复杂的，这里把具体代码分享给大家，方便大家为 image 设置有效的 version 头以及正确使能这个双程序可交替启动特性。

判断逻辑代码主要意思是仅当 image L 的版本不是 0xFFFFFFFF 且 image H 的版本是有效的（img_ver 高低16bit符合取反关系）情况下，如果 image L 版本无效或者 image L 版本有效但比 image H 版本低，则物理地址靠后的 image H 优先启动。除此以外其余情况，一律是物理地址靠前的 image L 优先启动。

uint32_t image_l_base = FlexSPIx_AMBA_BASE
uint32_t image_h_base = FlexSPIx_AMBA_BASE + FLEXSPI_NOR_SEC_IMAGE_OFFSET

uint32_t get_image_index(void)
{
    uint32_t redundant_boot = ((SRC->GPR[9] & 0x0C000000) >> 26);

    static uint32_t image_index[] = { 0, 0 };
    img_ver_t image_l_version = *(img_ver_t *)(image_l_base + 0x600);
    img_ver_t image_h_version = *(img_ver_t *)(image_h_base + 0x600);
    if ((image_l_version.version != 0xFFFFu || image_l_version.inversion != 0xFFFFu) &&
        ((0xFFFFu & image_h_version.version) == (0xFFFFu ^ image_h_version.inversion)) &&
        ((0xFFFFu & image_l_version.version) != (0xFFFFu ^ image_l_version.inversion) || (image_l_version.version < image_h_version.version)))
    {
        image_index[0] = 1;
    }
    else
    {
        image_index[1] = 1;
    }

    return image_index[redundant_boot];
}

痞子衡在MIMXRT1170-EVK 开发板上对image 版本设置情况也做了比较全面的实测，测试结果如下：

四、一些关于image的注意事项

1）虽然文中所有的测试均是针对 XIP image，但这个冗余程序/双程序可交替启动特性对于 Non-XIP image 也同样适用。

2）如果是 XIP image，其链接地址不一定要固定在偏移 0x2000 处，因为 IVT 的存在，其是可以链接在偏移 0x2000 之后的任意位置的。

3）如果是 Non-XIP image，在 SDK 包里无法直接生成含启动头的 Non-XIP image binary，这时候可以先使用 MCUBootUtility 主界面的 All-In-One 操作下载一次 image，再通过通用编程器界面 Read 操作读回来便是含启动头的 Non-XIP image binary。

相关阅读
《i.MX RT1060/1010上串行NOR Flash冗余程序启动设计》

来源：恩智浦MCU加油站
免责声明：本文为转载文章，转载此文目的在于传递更多信息，版权归原作者所有。本文所用视频、图片、文字如涉及作品版权问题，请联系小编进行处理（联系邮箱：cathy@eetrend.com）。

i.MX RT1170的CCM模块内置了一个时钟观测器，全称为Clock Observe。它就像示波器一样可以检测时钟的运行频率，在没有示波器的情况或者开发低功耗应用时非常有用。强大的特点，在于它几乎可以测量芯片内几乎所有的时钟源（Clock Source）和时钟根(Clock Root)。

可测量的时钟源高达22个，基本覆盖了RT1170所有的时钟源。可测量的时钟根高达83个，覆盖了绝大多数的外设时钟根。具体可以测量的时钟源和时钟根列表可以参考 fsl_clock.h的宏定义，搜索关键词Clock OBSERVE SIGNALS即可找到相关的列表。

介绍完基本功能，我们来看一下如何使用这个时钟观测器，也就是如何获取想观测的时钟频率，非常简单，调用下面的API函数接口即可：

uint32_t CLOCK_GetFreqFromObs(uint32_tobsSigIndex, uint32_t obsIndex)

举个例子，用户想知道现在RT1170的主频，Bus总线的时钟频率，怎么办呢？凉拌！

CLOCK_GetFreqFromObs(CCM_OBS_M7_CLK_ROOT)；
CLOCK_GetFreqFromObs(CCM_OBS_M4_CLK_ROOT)；
CLOCK_GetFreqFromObs(CCM_OBS_BUS_CLK_ROOT)；
CLOCK_GetFreqFromObs(CCM_OBS_BUS_LPSR_CLK_ROOT)；

直接调用的话，看起来不太方便，通过串口把这些数值打印到终端上，看起来就方便很多了。

PRINTF("M7 CLK is %d MHz\r\n", CLOCK_GetFreqFromObs(CCM_OBS_M7_CLK_ROOT) / 1000000);
PRINTF("M4 CLK is %d MHz\r\n", CLOCK_GetFreqFromObs(CCM_OBS_M4_CLK_ROOT) / 1000000);
PRINTF("BUS CLK is %d MHz\r\n", CLOCK_GetFreqFromObs(CCM_OBS_BUS_CLK_ROOT) / 1000000);
PRINTF("BUS LPSR CLK is %d MHz\r\n", CLOCK_GetFreqFromObs(CCM_OBS_BUS_LPSR_CLK_ROOT) / 1000000);

下图为打印的结果，并不完全是上面代码真实的状态，只是看个意思，我们通过上面的函数即可测量出当前对应时钟根的工作频率。

将函数中的参数进行变换，我们就可以测量自己感兴趣的时钟频率。那么这个观测器在实际中都有哪些作用呢？

1）测量时钟的工作频率

在运行不熟悉代码的时候，不知道别人时钟是怎么配置的时候，获取其工作频率。而不用一行一行翻代码进行工作频率解析。笔者自己经常观测的就是PLL的PFD时钟频率。

2）确定时钟源是否开启

如果把之前提到的函数进行细部探究，便会发现程序中有一行while（），等待测量结束非0的状态。这行代码的功能主要是等待测量结果更新，如果时钟源没开则会在这里一直等下去。
利用这个特性，就可以判断被测时钟源是否开启。当然这也是双刃剑，调试的时候要记得这个特性，不然程序运行到这里之后就会停下来，一直等下去。

需要注意的点：

1）OBS的观测需要依靠外部的32K晶振时钟

2）OBS的功能仅限于调试目的，精度上肯定比不上示波器，但是看个大概还是问题不大的。再强调一遍哦，调试目的，精度不保证，就看个大概！

3）OBS应该在室温下工作，并且观测的频率不应该超过400MHz。关于400MHz这个限制，笔者在调试的过程中发现，其实大于这个数值也能测准，也能用。但是不负责，不保证，毕竟有这么大个NOTE在RM里写着呢。

来源：恩智浦MCU加油站
免责声明：本文为转载文章，转载此文目的在于传递更多信息，版权归原作者所有。本文所用视频、图片、文字如涉及作品版权问题，请联系小编进行处理（联系邮箱：cathy@eetrend.com）。