在痞子衡舊文《RT四位數(shù)Boot模式》里的1.2.1 Serial Downloader模式；《RT三位數(shù)Boot模式》里的p1.2.2 Serial Boot模式里都介紹到了i.MXRT芯片內(nèi)置ROM程序里支持與主機(jī)進(jìn)行數(shù)據(jù)交互，而交互的通信協(xié)議均是blhost協(xié)議(這最早來自于飛思卡爾Kinetis系列ROM), 有了這個(gè)功能，我們便可以直接將應(yīng)用程序灌進(jìn)i.MXRT內(nèi)部SRAM去加載執(zhí)行，這個(gè)功能在多處理器系統(tǒng)里(尤其是i.MXRT作為協(xié)處理器)大有用處。

最近有個(gè)客戶設(shè)計(jì)了高通AR1+恩智浦i.MXRT600 的主從系統(tǒng)，RT600作為協(xié)處理器直接通過SPI接口從主處理器AR1接收應(yīng)用程序App并加載到自身內(nèi)部SRAM執(zhí)行，這樣硬件上便可省去RT600的專屬非易失性存儲(chǔ)器?？蛻粢呀?jīng)將blhost協(xié)議代碼集成進(jìn)了AR1程序里，但在實(shí)際測(cè)試過程中發(fā)現(xiàn)有一定概率導(dǎo)致RT600程序加載失敗，RT600 ROM會(huì)返回kStatus_AbortDataPhase (0x5A,0xA3), 這是怎么回事？今天痞子衡就來聊聊這個(gè)話題：

一、i.MXRT與主機(jī)交互方法

我們首先簡(jiǎn)單回顧下i.MXRT內(nèi)置ROM程序配套的與主機(jī)交互方法，有如下三種。其中方法一是比較常用的，把PC當(dāng)作主機(jī)，因?yàn)?a href="http://www.www27dydycom.cn/tags/uart/" target="_blank">UART/USB接口可以直接從PC引出，這種方式一般集成在上位機(jī)GUI工具里（比如恩智浦官方的SPT以及痞子衡的NXP-MCUBootUtility)。方法二本質(zhì)上和方式一差不多，主機(jī)仍然是PC, 只不過通信接口是SPI/I2C，因?yàn)闊o法直接從PC引出，需要有一個(gè)橋接板，恩智浦一共做了三種不同的橋接實(shí)現(xiàn)。方式三就是本文提及的客戶所用到的方法，把主處理器當(dāng)作主機(jī)，因?yàn)樘幚砥鹘涌谪S富，所以不管哪種通信方式均可以直連。

因?yàn)榉绞揭缓头绞蕉梢灾苯邮褂枚髦瞧痔峁┑呐涮坠ぞ哝?，因此blhost協(xié)議實(shí)現(xiàn)細(xì)節(jié)以及注意事項(xiàng)都被包在了工具鏈里面，客戶使用起來基本不會(huì)遇到問題。而方式三需要客戶自己移植實(shí)現(xiàn)blhost協(xié)議到主處理器代碼里，這可能會(huì)遇到一些協(xié)議細(xì)節(jié)上的設(shè)計(jì)問題。

這里需要特別提一下方式二里的Embedded Host橋接實(shí)現(xiàn)，在恩智浦官網(wǎng)MCUBoot主頁我們可以下載到NXP_Kinetis_Bootloader_2_0_0.zip包，NXP_Kinetis_Bootloader_2_0_0validationembedded_host 路徑下我們可以找到基于Kinetis K65的實(shí)現(xiàn)，如果你想移植blhost協(xié)議到處理器上運(yùn)行，不妨參考這個(gè)代碼。

二、i.MXRT從主機(jī)接收數(shù)據(jù)包超時(shí)機(jī)制

現(xiàn)在我們談回到blhost協(xié)議本身，這是一套數(shù)據(jù)包傳輸格式與支持命令的定義集合。打開RT600參考手冊(cè)的Non-Secure Boot ROM章節(jié)，可以找到具體的協(xié)議細(xì)節(jié)，這里就不再贅述。我們只取其中關(guān)于write-memory命令的介紹，主機(jī)給i.MXRT下載數(shù)據(jù)(App)主要就是借助這個(gè)命令。

write-memory命令的過程其實(shí)很簡(jiǎn)單，主機(jī)(Host)先要發(fā)送含write-memory信息的命令包(0x5A, 0xA4 ...) 給i.MXRT(圖中叫target)，收到確認(rèn)的回復(fù)(0x5A, 0xA1)后，主機(jī)繼續(xù)發(fā)送含App程序數(shù)據(jù)的數(shù)據(jù)包(0x5A, 0xA5...)，等待i.MXRT處理完成返回確認(rèn)信息，然后主機(jī)不斷發(fā)送數(shù)據(jù)包，直到App數(shù)據(jù)全部發(fā)送完成，最后還有一個(gè)結(jié)束命令包。

Note: 注意這里的App數(shù)據(jù)不是一個(gè)數(shù)據(jù)包就全部發(fā)送完的，而是被拆分成了很多個(gè)小數(shù)據(jù)包，每個(gè)小數(shù)據(jù)包最大長(zhǎng)度是512字節(jié)。拆分成小包的目的是防止通信過程中有干擾導(dǎo)致數(shù)據(jù)錯(cuò)誤，出現(xiàn)錯(cuò)誤就只需要重新發(fā)送該包數(shù)據(jù)。如果不拆分?jǐn)?shù)據(jù)包，出現(xiàn)錯(cuò)誤就得全部App數(shù)據(jù)重發(fā)，效率太低。

關(guān)于每個(gè)數(shù)據(jù)小包的接收與發(fā)送, i.MX RT均設(shè)計(jì)了超時(shí)機(jī)制保護(hù)。如果主機(jī)已經(jīng)開始發(fā)送當(dāng)前小包數(shù)據(jù)(發(fā)完包固定起始字節(jié)0x5A后為超時(shí)起點(diǎn))，那么需要在規(guī)定時(shí)間內(nèi)（包剩余長(zhǎng)度(Bytes)*10ms/Bytes) 完成該包數(shù)據(jù)發(fā)送，如果超時(shí)時(shí)間內(nèi)未完成，i.MX RT則返回 kStatus_AbortDataPhase。至于read-memory時(shí)主機(jī)接收小包數(shù)據(jù)時(shí)超時(shí)機(jī)制相同，只不過時(shí)間單元是20ms/Bytes。

Note1：RT500/600/700 ROM程序里數(shù)據(jù)包處理超時(shí)機(jī)制是一樣的，發(fā)送和接收均有超時(shí)。

Note2：RT1160/1170/1180 ROM程序里數(shù)據(jù)包處理僅有接收超時(shí)，沒有發(fā)送超時(shí)。

當(dāng)然文檔里還有未詳盡的地方，主機(jī)每發(fā)完一小包數(shù)據(jù)后都需要讀確認(rèn)信息(0x5A, 0xA1)，確認(rèn)信息這里是否有超時(shí)限制？如果有，是怎樣的機(jī)制？

痞子衡就不賣關(guān)子了，這里是需要特別注意的，當(dāng)主機(jī)發(fā)完一包數(shù)據(jù)后，i.MXRT需要及時(shí)處理數(shù)據(jù)的，由于這里是加載程序進(jìn)內(nèi)部SRAM，所以就是將該數(shù)據(jù)包從緩沖區(qū)搬到 SRAM指定位置，這個(gè)時(shí)間t2很短，文檔里并未給出。t3是比較關(guān)鍵的時(shí)間，這里的計(jì)時(shí)起點(diǎn)并不是主機(jī)收到ACK包的第一個(gè)字節(jié)，而是i.MXRT處理完數(shù)據(jù)搬移后就開始了，因此主機(jī)每次發(fā)完數(shù)據(jù)包之后, 都需要在t2+t3的時(shí)間內(nèi)將確認(rèn)信息數(shù)據(jù)包及時(shí)讀走，否則i.MXRT則返回kStatus_AbortDataPhase。

那么問題來了，如果一小包數(shù)據(jù)是200 bytes（包含 0x5A包頭等信息），請(qǐng)問主機(jī)發(fā)送數(shù)據(jù)和接收確認(rèn)的超時(shí)時(shí)間分別是多少？答案是1990ms和t2+40ms (這里主機(jī)接收確認(rèn)消息只拿了2 bytes數(shù)據(jù))。

三、客戶主機(jī)發(fā)送數(shù)據(jù)包設(shè)計(jì)

最后回到客戶的問題，經(jīng)過和客戶的溝通，主處理器AR1運(yùn)行得是一個(gè)非實(shí)時(shí)操作系統(tǒng)。在給RT600加載App程序過程中會(huì)出現(xiàn)任務(wù)調(diào)度情況，發(fā)送完一個(gè)小數(shù)據(jù)包后，因?yàn)槿蝿?wù)調(diào)度的關(guān)系，導(dǎo)致主機(jī)讀取確認(rèn)消息(0x5A, 0xA1)的時(shí)間間隔不確定，有時(shí)候小于40ms, 有時(shí)候會(huì)超出40ms, 顯然這是不符合blhost協(xié)議超時(shí)機(jī)制規(guī)定的。

此外即使能滿足超時(shí)要求，但是主機(jī)如何讀取確認(rèn)消息也是有講究的，嘗試讀取首字節(jié)0x5A要滿足至少100us延時(shí)(如果存在多次嘗試的話，兩次嘗試之間也要延時(shí)), 而拿到首字節(jié)后，再去讀取第二個(gè)字節(jié) 0xA1, 也需要至少延時(shí)50us。

最后還有一點(diǎn)需要提醒，因?yàn)镽T500/600/700中存在多個(gè)核（CM33、DSP、NPU等), 所以主機(jī)有時(shí)候給i.MXRT灌的程序數(shù)據(jù)是糅合了多個(gè)核代碼，write-memory命令里提供的App長(zhǎng)度信息要和實(shí)際要寫入的數(shù)據(jù)量匹配，否則i.MXRT也會(huì)返回異常狀態(tài)碼。

NXP

恩智浦致力于打造安全的連接和基礎(chǔ)設(shè)施解決方案，為智慧生活保駕護(hù)航。