痞子衡嵌入式：了解主从系统中i.MXRT系列MCU从主处理器接收App数据包超时机制

Wpt2GuNNMVR

<hr>　　大家好，我是痞子衡，是正经搞技术的痞子。今天痞子衡给大家介绍的是主从系统中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。至于 read-memory 时主机接收小包数据时超时机制相同，只不过时间单元是 20ms/Bytes。

• Note1：RT500/600/700 ROM 程序里数据包处理超时机制是一样的，发送和接收均有超时。
  
• Note2：RT1160/1170/1180 ROM 程序里数据包处理仅有接收超时，没有发送超时。
  

　　当然文档里上述表述有未尽的地方，主机每发完一小包数据后都需要读确认信息(0x5A, 0xA1)，确认信息这里是否有超时限制？如果有，是怎样的机制？痞子衡就不卖关子了，这里是需要特别注意的，当主机发完一包数据后，i.MXRT 需要及时处理数据的，由于这里是加载程序进内部 SRAM，所以就是将该数据包从缓冲区搬到 SRAM 指定位置，这个时间 t2 很短，文档里并未给出。t3 是比较关键的时间，这里的计时起点并不是主机收到 ACK 包的第一个字节，而是 i.MXRT 处理完数据搬移后就开始了，因此主机每次发完数据包之后，都需要在 t2+t3 的时间内将确认信息数据包及时读走，否则 i.MXRT 则返回 kStatus_AbortDataPhase。

　　那么问题来了，如果一小包数据是 200 bytes（包含 0x5A 包头等信息），请问主机发送数据和接收确认的超时时间分别是多少？答案是 1990ms 和 t2+40ms（这里主机接收确认消息只拿了 2 bytes 数据）。
三、客户主机发送数据包设计

　　最后回到客户的问题，经过和客户的沟通，主处理器 AR1 运行得是一个非实时操作系统。在给 RT600 加载 App 程序过程中会出现任务调度情况，发送完一个小数据包后，因为任务调度的关系，导致主机读取确认消息(0x5A, 0xA1)的时间间隔不确定，有时候小于 40ms，有时候会超出 40ms，显然这是不符合 blhost 协议超时机制规定的。
　　至此，主从系统中i.MXRT系列MCU从主处理器接收App数据包超时机制痞子衡便介绍完毕了，掌声在哪里~~~
欢迎订阅

文章会同时发布到我的 博客园、CSDN、微信公众号、知乎、与非网、电子技术应用AET、电子星球、51CTO 平台上。
微信搜索"痞子衡嵌入式"或者扫描下面二维码，就可以在手机上第一时间看了哦。