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

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

一、i.MXRT與主機交互方法

我們首先簡單回顧下i.MXRT內(nèi)置ROM程序配套的與主機交互方法，有如下三種。其中方法一是比較常用的，把PC當(dāng)作主機，因為UART/USB接口可以直接從PC引出，這種方式一般集成在上位機GUI工具里（比如恩智浦官方的SPT以及痞子衡的NXP-MCUBootUtility)。方法二本質(zhì)上和方式一差不多，主機仍然是PC, 只不過通信接口是SPI/I2C，因為無法直接從PC引出，需要有一個橋接板，恩智浦一共做了三種不同的橋接實現(xiàn)。方式三就是本文提及的客戶所用到的方法，把主處理器當(dāng)作主機，因為處理器接口豐富，所以不管哪種通信方式均可以直連。

因為方式一和方式二均可以直接使用恩智浦提供的配套工具鏈，因此blhost協(xié)議實現(xiàn)細節(jié)以及注意事項都被包在了工具鏈里面，客戶使用起來基本不會遇到問題。而方式三需要客戶自己移植實現(xiàn)blhost協(xié)議到主處理器代碼里，這可能會遇到一些協(xié)議細節(jié)上的設(shè)計問題。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

NXP

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