竟有可以從AP直接加載程序啟動的MCU！

大家好，我是痞子衡，是正經(jīng)搞技術(shù)的痞子。今天痞子衡給大家介紹的是主從系統(tǒng)中i.MXRT系列MCU從主處理器接收App數(shù)據(jù)包超時機制。

在痞子衡舊文?《RT四位數(shù)Boot模式》?里的 1.2.1 Serial Downloader 模式、《RT三位數(shù)Boot模式》?里的 1.2.2 Serial Boot 模式里都介紹到了 i.MXRT 芯片內(nèi)置 ROM 程序里支持與主機進(jìn)行數(shù)據(jù)交互，而交互的通信協(xié)議均是 blhost 協(xié)議（這最早來自于飛思卡爾 Kinetis 系列 ROM ），有了這個功能，我們便可以直接將應(yīng)用程序灌進(jìn) 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é)議代碼集成進(jìn)了 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)細(xì)節(jié)以及注意事項都被包在了工具鏈里面，客戶使用起來基本不會遇到問題。而方式三需要客戶自己移植實現(xiàn) blhost 協(xié)議到主處理器代碼里，這可能會遇到一些協(xié)議細(xì)節(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é)議細(xì)節(jié)，這里就不再贅述。我們只取其中關(guān)于 write-memory 命令的介紹，主機給 i.MXRT 下載數(shù)據(jù)(App)主要就是借助這個命令。

write-memory 命令的過程其實很簡單，主機(Host)先要發(fā)送含 write-memory 信息的命令包(0x5A, 0xA4 ...) 給 i.MXRT (圖中叫 target)，收到確認(rèn)的回復(fù)(0x5A, 0xA1)后，主機繼續(xù)發(fā)送含 App 程序數(shù)據(jù)的數(shù)據(jù)包(0x5A, 0xA5 ...)，等待 i.MXRT 處理完成返回確認(rèn)信息，然后主機不斷發(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ù)。如果不拆分?jǐn)?shù)據(jù)包，出現(xiàn)錯誤就得全部 App 數(shù)據(jù)重發(fā)，效率太低。

關(guān)于每個數(shù)據(jù)小包的接收與發(fā)送，i.MXRT 均設(shè)計了超時機制保護(hù)。如果主機已經(jīng)開始發(fā)送當(dāng)前小包數(shù)據(jù)(發(fā)完包固定起始字節(jié) 0x5A 后為超時起點)，那么需要在規(guī)定時間內(nèi)（包剩余長度(Bytes) * 10ms/Bytes）完成該包數(shù)據(jù)發(fā)送，如果超時時間內(nèi)未完成，i.MXRT 則返回 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ù)后都需要讀確認(rèn)信息(0x5A, 0xA1)，確認(rèn)信息這里是否有超時限制？如果有，是怎樣的機制？痞子衡就不賣關(guān)子了，這里是需要特別注意的，當(dāng)主機發(fā)完一包數(shù)據(jù)后，i.MXRT 需要及時處理數(shù)據(jù)的，由于這里是加載程序進(jìn)內(nèi)部 SRAM，所以就是將該數(shù)據(jù)包從緩沖區(qū)搬到 SRAM 指定位置，這個時間 t2 很短，文檔里并未給出。t3 是比較關(guān)鍵的時間，這里的計時起點并不是主機收到 ACK 包的第一個字節(jié)，而是 i.MXRT 處理完數(shù)據(jù)搬移后就開始了，因此主機每次發(fā)完數(shù)據(jù)包之后，都需要在 t2+t3 的時間內(nèi)將確認(rèn)信息數(shù)據(jù)包及時讀走，否則 i.MXRT 則返回 kStatus_AbortDataPhase。

那么問題來了，如果一小包數(shù)據(jù)是 200 bytes（包含 0x5A 包頭等信息），請問主機發(fā)送數(shù)據(jù)和接收確認(rèn)的超時時間分別是多少？答案是 1990ms 和 t2+40ms（這里主機接收確認(rèn)消息只拿了 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)致主機讀取確認(rèn)消息(0x5A, 0xA1)的時間間隔不確定，有時候小于 40ms，有時候會超出 40ms，顯然這是不符合 blhost 協(xié)議超時機制規(guī)定的。

至此，主從系統(tǒng)中i.MXRT系列MCU從主處理器接收App數(shù)據(jù)包超時機制痞子衡便介紹完畢了，掌聲在哪里~~~