如何实现i.MXRT系列MCU从主处理器接收App数据包超时机制的最佳超时处理策略？

大家好，我是痞子衡，是正经搞技术的痞子。今天痞子衡给大家介绍的是主从系统中i.MXRT系列MCU从主处理器接收App数据包超时机制。 　　在痞子衡旧文 《RT四位数Boot模式》 里的 1.2.1 Serial Downloader 模式、《RT三位数Boot模式》 里的 1.2.2 Serial Boot 模式里都介绍到了 i.MXRT 芯片内置 ROM 程序里支持与主机进行数据交互，而交互的通信协议均是 blhost 协议（这最早来自于飞思卡尔 Kinetis 系列 ROM ），有了这个功能，我们便可以直接将应用程序灌进 i.MXRT 内部 SRAM 去加载执行，这个功能在多处理器系统里（尤其是 i.MXRT 作为协处理器）大有用处。 　　最近有一个客户设计了高通 AR1 + 恩智浦 i.MXRT600 的主从系统，RT600 作为协处理器直接通过 SPI 接口从主处理器 AR1 接收应用程序 App 并加载到自身内部 SRAM 执行，这样硬件上便可省去 RT600 的专属非易失性存储器。客户已经将 blhost 协议代码集成进了 AR1 程序里，但在实际测试过程中发现有一定概率导致 RT600 程序加载失败，RT600 ROM 会返回 kStatus_AbortDataPhase（0x5A,0xA3），这是怎么回事？今天痞子衡就来聊聊这个话题： 一、i.MXRT与主机交互方法 　　我们首先简单回顾下 i.MXRT 内置 ROM 程序配套的与主机交互方法，有如下三种。其中方法一是比较常用的，把 PC 当作主机，因为 UART/USB 接口可以直接从 PC 引出，这种方式一般集成在上位机 GUI 工具里（比如恩智浦官方的 SPT 以及痞子衡的 NXP-MCUBootUtility)。方法二本质上和方式一差不多，主机仍然是 PC，只不过通信接口是 SPI/I2C，因为无法直接从 PC 引出，需要有一个桥接板，恩智浦一共做了三种不同的桥接实现。方式三就是本文提及的客户所用到的方法，把主处理器当作主机，因为处理器接口丰富，所以不管哪种通信方式均可以直连。 　　因为方式一和方式二均可以直接使用恩智浦提供的配套工具链，因此 blhost 协议实现细节以及注意事项都被包在了工具链里面，客户使用起来基本不会遇到问题。而方式三需要客户自己移植实现 blhost 协议到主处理器代码里，这可能会遇到一些协议细节上的设计问题。 　　这里需要特别提一下方式二里的 Embedded Host 桥接实现，在恩智浦官网 MCUBoot 主页我们可以下载到 NXP_Kinetis_Bootloader_2_0_0.zip 包，在 \NXP_Kinetis_Bootloader_2_0_0\validation\embedded_host 路径下我们可以找到基于 Kinetis K65 的实现，如果你想移植 blhost 协议到处理器上运行，不妨参考这个代码。 二、i.MXRT从主机接收数据包超时机制 　　现在我们谈回到 blhost 协议本身，这是一套数据包传输格式与支持命令的定义集合。打开 RT600 参考手册的 Non-Secure Boot ROM 章节，可以找到具体的协议细节，这里就不再赘述。我们只取其中关于 write-memory 命令的介绍，主机给 i.MXRT 下载数据(App)主要就是借助这个命令。 　　write-memory 命令的过程其实很简单，主机(Host)先要发送含 write-memory 信息的命令包(0x5A, 0xA4 ...) 给 i.MXRT (图中叫 target)，收到确认的回复(0x5A, 0xA1)后，主机继续发送含 App 程序数据的数据包(0x5A, 0xA5 ...)，等待 i.MXRT 处理完成返回确认信息，然后主机不断发送数据包，直到 App 数据全部发送完成，最后还有一个结束命令包。 Note: 注意这里的 App 数据不是一个数据包就全部发送完的，而是被拆分成了很多个小数据包，每个小数据包最大长度是 512 字节。拆分成小包的目的是防止通信过程中有干扰导致数据错误，出现错误就只需要重新发送该包数据。如果不拆分数据包，出现错误就得全部 App 数据重发，效率太低。 　　关于每个数据小包的接收与发送，i.MXRT 均设计了超时机制保护。如果主机已经开始发送当前小包数据(发完包固定起始字节 0x5A 后为超时起点)，那么需要在规定时间内（包剩余长度(Bytes) * 10ms/Bytes）完成该包数据发送，如果超时时间内未完成，i.MXRT 则返回 kStatus_AbortDataPhase。