在痞子衡舊文《RT四位數Boot模式》里的1.2.1 Serial Downloader模式；《RT三位數Boot模式》里的p1.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_0validationembedded_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.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是比較關鍵的時間，這里的計時起點并不是主機收到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協議超時機制規定的。

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

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

NXP

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