您现在的位置是：锐评时讯 > 生活
主从体系中i.MXRT系列MCU从主处理器接纳App数据包超时机制
锐评时讯2025-05-29 07:13:53【生活】3人已围观
简介在痞子衡旧文《RT四位数Boot形式》里的1.2.1 Serial Downlo。ad。er形式；《RT三位数Boot形式》里的p1.2.2 Serial Boot形式里都介绍到了i.MXRT芯片内置
在痞子衡旧文《RT四位数Boot形式》里的1.2.1 Serial Downlo。ad。er形式；《RT三位数Boot形式》里的p1.2.2 Serial Boot形式里都介绍到了i.MXRT芯片内置。ROM。程序里支撑与主机进行数据交互，而交互的。通讯。协议均是blhost协议(这最早来自于飞思卡尔Kine。ti。s系列ROM), 有了这个功用，咱们便能够直接将应用程序灌进i.MXRT内部S。RAM。去加载履行，这个功用在多。处理器。体系里(尤其是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。-。MCU。BootUtility)。办法二本质上和办法一差不多，主机仍然是PC, 只不过。通讯接口。是SPI/。I2C。，由于无法直接从PC引出，需求有一个桥接板，恩智浦总共做了三种不同的桥接完结。办法三便是本文提及的客户所用到的办法，把主处理器当作主机，由于处理器接口丰厚，所以不论哪种通讯办法均能够直连。
由于办法一和办法二均能够直接运用恩智浦供给的配套东西链，因而blhost协议完结细节以及留意事项都被包在了东西链里边，客户运用起来根本不会遇到问题。而办法三需求客户自己移植完结blhost协议到主处理器代码里，这可能会遇到一些协议细节上的规划问题。
这儿需求特别提一下办法二里的Embedded Host桥接完结，在恩智浦官网MCUBoot主页咱们能够下载到NXP_Kinetis_Bootloader_2_0_0.zip包，NXP_Kinetis_Bootloader_2_0_0validationembedded_host 途径下咱们能够找到根据Kinetis K65的完结，假如你想移植blhost协议到处理器上运转，无妨参阅这个代码。
二、i.MXRT从主机接纳数据包超时机制。
现在咱们谈回到blhost协议自身，这是一套数据包传输格局与支撑指令的界说调集。翻开RT600参阅手册的Non-Secure Boot ROM章节，能够找到详细的协议细节，这儿就不再赘述。咱们只取其间关于wri。te。-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.MX RT均规划了超时机制维护。假如主机现已开端发送当时小包数据(发完包固定开端字节0x5A后为超时起点)，那么需求在规则时刻内（包剩下长度(Bytes)*10ms/Bytes) 完结该包数据发送，假如超时时刻内未完结，i.MX RT则回来 kStatus_AbortDataPhase。至于read-memory时主机接纳小包数据时超时机制相同，只不过时刻单元是20ms/Bytes。
Note1：RT500/600/700 ROM程序里数据包处理超时机制是相同的，发送和接纳均有超时。
Note2：RT1160/1170/1180 ROM程序里数据包处理仅有接纳超时，没有发送超时。
当然文档里还有未翔实的当地，主机每发完一小包数据后都需求读承认信息(0x5A, 0xA1)，承认信息这儿是否有超时约束？假如有，是怎样的机制？
痞子衡就不卖关子了，这儿是需求特别留意的，当主机发完一包数据后，i.MXRT需求及时处理数据的，由于这儿是加载程序进内部SRAM，所以便是将该数据包从缓冲区搬到 SRAM指定方位，这个时刻t2很短，文档里并未给出。t3是比较要害的时刻，这儿的计时起点并不是主机收到。AC。K包的第一个字节，而是i.MXRT处理完数据搬移后就开端了，因而主机每次发完数据包之后, 都需求在t2+t3的时刻内将承认信息数据包及时读走，不然i.MXRT则回来kStatus_AbortDataPhase。
那么问题来了，假如一小包数据是200 bytes（包括 0x5A包头号信息），请问主机发送数据和接纳承认的超时时刻别离是多少？答案是1990ms和t2+40ms (这儿主机接纳承认音讯只拿了2 bytes数据)。
三、客户主机发送数据包规划。
最终回到客户的问题，通过和客户的交流，主处理器AR1运转得是一个非实时操作体系。在给RT600加载App程序进程中会呈现使命调度状况，发送完一个小数据包后，由于使命调度的联系，导致主机读取承认音讯(0x5A, 0xA1)的时刻距离不确定，有时候小于40ms, 有时候会超出40ms, 明显这是不符合blhost协议超时机制规则的。
此外即便能满意超时要求，可是主机怎么读取承认音讯也是有考究的，测验读取首字节0x5A要满意至少100us延时(假如存在屡次测验的话，两次测验之间也要延时), 而拿到首字节后，再去读取第二个字节 0xA1, 也需求至少延时50us。
最终还有一点需求提示，由于RT500/600/700中存在多个核（CM33、。DSP。、NPU等), 所以主机有时候给i.MXRT灌的程序数据是糅合了多个核代码，write-memory指令里供给的App长度信息要和实践要写入的数据量匹配，不然i.MXRT也会回来反常状况码。
NXP。
恩智浦致力于打造安全的衔接和基础设施解决方案，为才智日子保驾护航。
很赞哦!（8147）