前陣子負(fù)責(zé)一個需要同時兼顧 Linux 生態(tài)和實時控制的項目最終把選型落在 STM32MP257 上。這顆芯片最大的看點是 Cortex-A35 旁邊那個 Cortex-M33 核用 FreeRTOS 在里面跑實時邏輯再通過 OpenAmp 和 Linux 側(cè)做無感通信。很多人一聽到 MPU 就以為又是嵌入式 Linux 那一套實際上 M33 FreeRTOS 才是真正決定項目成敗的部分。這篇文章從 SDK 目錄結(jié)構(gòu)、啟動順序、DTS 內(nèi)存預(yù)留一直聊到 RPMsg 收發(fā)、緩存一致性、量產(chǎn)心跳監(jiān)控的完整過程。準(zhǔn)備在 STM32MP25x 上做異構(gòu)開發(fā)的朋友可以直接當(dāng)避坑手冊用。1. 從MP1到MP2為什么這次我選了STM32MP257的M33核1.1 STM32MP257不是又一個跑Linux的開發(fā)板STM32MP257 屬于 STM32MP25x 系列內(nèi)部是多核異構(gòu)架構(gòu)。主處理器是 Cortex-A35可以跑完整的 Linux協(xié)處理器是 Cortex-M33適合跑裸機(jī)或者 FreeRTOS。很多人看到 MPU 的第一反應(yīng)是“主頻多少、內(nèi)存多大、能不能跑容器”但這些指標(biāo)只衡量了 A35 那半邊。真正讓 MP257 和普通 Linux 板卡拉開差距的是那顆 M33 核。傳統(tǒng)做法里如果一個系統(tǒng)既需要 Linux 的業(yè)務(wù)吞吐又需要對電機(jī)、IO、協(xié)議棧做“微秒級響應(yīng)”往往會外掛一顆 MCU比如 STM32F4 或者 GD32。主 SoC 和 MCU 之間用 UART、SPI、CAN 通信。通信協(xié)議自己要定義可靠性自己要保證板級面積和功耗也多了一份。MP257 把 M33 做進(jìn)同一顆 SoC兩個核之間的通信通過共享內(nèi)存和硬件郵箱完成延遲比外掛串口低一兩個數(shù)量級。從項目角度講這意味著可以省掉一顆外部 MCU減少整個 BOM 的物料種類和貼片面積。另一方面M33 與 A35 共享同一片 DDR通過 RPMsg 傳數(shù)據(jù)天然比“外部 MCU 串口 協(xié)議解析”更穩(wěn)。當(dāng)然省掉外部 MCU 不意味著省事因為跨核調(diào)試、內(nèi)存隔離、固件加載這些問題全部從硬件層級轉(zhuǎn)移到了軟件工程里。1.2 M33核在整個系統(tǒng)里的角色實時性與安全島M33 在 MP257 里承擔(dān)什么角色直接決定了 FreeRTOS 工程怎么寫。如果只是想讓 A35 跑 LinuxM33 跑一個流水燈那這顆核就浪費(fèi)了。我這次項目里M33 要做三類事第一類是硬實時控制。比如電流環(huán)的 PWM 更新周期是 20kHzLinux 的調(diào)度根本保證不了這種確定性。M33 本身就是單片機(jī)內(nèi)核配合定時器中斷能穩(wěn)定完成。第二類是高速 IO 響應(yīng)。MP257 有不少 GPIO 和低速外設(shè)掛在 M33 側(cè)比如部分 UART、I2C、SPI、定時器。把這些外設(shè)放在 M33 上A35 側(cè) Linux 發(fā)生調(diào)度抖動或者網(wǎng)絡(luò)風(fēng)暴時M33 依然能按自己的節(jié)奏處理。第三類是安全兜底。Cortex-M33 支持 TrustZone可以把一部分敏感邏輯放在安全世界里。即使 Linux 側(cè)被攻破M33 里的安全固件仍然可以獨立運(yùn)行。不能說這是百分之百的安全方案但相比“所有邏輯都跑在同一個非安全環(huán)境下”攻擊面小了很多。換句話說M33 不是一個“附贈品”而是一塊獨立的實時島。FreeRTOS 在這個島上跑OpenAmp 是島和大陸之間的橋。橋怎么搭比島上怎么蓋樓更重要。1.3 和MP157對比M33核的資源邊界用過 STM32MP157 的人應(yīng)該知道MP157 的協(xié)處理器是 Cortex-M4主核是 A7。到了 MP257主核升級為 A35協(xié)處理器升級為 M33。M33 相比 M4多了 TrustZone、MPU以及更完整的中斷控制器支持。單看頻率M33 在 MP257 上通常能跑幾百 MHz算力比老 M4 有提升但和 A35 不是一個量級。M33 可訪問的資源不是無窮的。它有自己的 TCM、SRAM也能通過總線訪問 DDR。但 A35 上的 Linux 訪問同一片 DDR 時會涉及緩存一致性問題。簡單說M33 寫的內(nèi)存數(shù)據(jù)如果只是停在 CPU 的 cache 里A35 讀到的可能是舊值反過來也一樣。所以我們在設(shè)計共享內(nèi)存時必須明確這塊內(nèi)存是否允許 cache或者由軟件主動做 clean/invalidate。還有一個容易被忽略的地方M33 側(cè)能用的中斷不是所有 GIC SPI 都可以隨便綁。很多中斷源在硬件層面就固定了只能到 A35 或者只能到 M33。開始畫系統(tǒng)框圖前一定要對著參考手冊把每一條中斷線捋清楚否則后面寫代碼時才發(fā)現(xiàn)某個外設(shè)的中斷根本到不了 M33只能換方案。2. 動手前必須理清的啟動鏈與資源分配2.1 復(fù)位后的內(nèi)核啟動順序A35先跑還是M33先跑很多第一次做 AMP 的人都會問上電后 M33 要不要自己啟動FreeRTOS 是不是和 A35 的 Linux 一起跑答案要分階段看。MP257 默認(rèn)上電流程里ROM 引導(dǎo)鏈先啟動 A35 這一路上的 bootloader也就是 FSBL、TF-A、U-Boot最后進(jìn)入 Linux。M33 固件并不會自動跑起來它需要由 A35 側(cè)的軟件通過 remoteproc 機(jī)制加載并啟動。這個設(shè)計其實是刻意的M33 跑什么、什么時候跑、啟動后加載到什么地址應(yīng)該由整個系統(tǒng)的管理者這里通常是 Linux統(tǒng)一決策便于控制資源。所以項目調(diào)試初期最方便的做法是讓 Linux 起來之后用 remoteproc 接口把 M33 的 elf 文件加載到指定內(nèi)存然后觸發(fā)啟動。命令大概是echo start /sys/class/remoteproc/remoteproc0/state如果希望系統(tǒng)上電后 M33 自動運(yùn)行可以在 U-Boot 階段通過rproc start啟動 M33。兩套方案我建議初期先全部用手動方式確認(rèn)固件和共享內(nèi)存配置無誤后再優(yōu)化成自動啟動。原因很簡單手動啟動時 M33 出了問題你可以直接在 Linux 側(cè)重啟它不用反復(fù)燒錄整個系統(tǒng)。2.2 給M33分配內(nèi)存DTS reserved-memoryM33 固件要放在內(nèi)存里跑它和 Linux 的通信緩沖區(qū)也要放在內(nèi)存里。這里的難點在于Linux 自己也要用內(nèi)存如果 M33 使用的區(qū)域被 Linux 分配給別的進(jìn)程兩邊數(shù)據(jù)就會互相踩。所以第一步是在 Linux 的設(shè)備樹里把這些內(nèi)存區(qū)域聲明為 reserved。設(shè)備樹里常見寫法reserved-memory { #address-cells 2; #size-cells 2; ranges; m33_fw0x10000000 { reg 0x0 0x10000000 0x0 0x1000000; no-map; }; m33_rsc: m33-share0x10010000 { compatible shared-dma-pool; reg 0x0 0x10010000 0x0 0x100000; no-map; }; };這里no-map很關(guān)鍵。它告訴 Linux這塊區(qū)域不要建立頁表映射也不要給普通進(jìn)程用。M33 的固件代碼、資源表、共享內(nèi)存都放在這類區(qū)域里。如果沒有no-mapLinux 的頁表可能把這部分內(nèi)存映射為可緩存后面出現(xiàn)各種匪夷所思的奇怪錯誤。DTS 里還要將遠(yuǎn)程處理器節(jié)點指向這塊共享內(nèi)存。以官方 SDK 的常見方式為例rproc 節(jié)點會引用 reserved-memory 中的地址Linux remoteproc 驅(qū)動才知道加載固件到哪里以及從哪個地址讀取 M33 的資源表。這里所有地址必須是物理地址而且要和 M33 固件編譯時的鏈接地址嚴(yán)格一致。2.3 resource table和固件加載M33 固件和普通 MCU 固件有個很大的不同它需要附帶一個 resource table。這個表是給 Linux remoteproc 驅(qū)動的“配置清單”里面描述了 M33 側(cè)需要的內(nèi)存、vring 地址、備用資源等。Linux 啟動 M33 前會解析這個表把對應(yīng)的資源映射給 M33。在 M33 側(cè)工程里resource table 通常是一個 C 結(jié)構(gòu)體。重點是里面的 vring 地址。vring 是 OpenAmp 用于兩個核之間傳遞消息的“環(huán)形緩沖區(qū)”它必須位于兩塊都很容易訪問且不會被動過的內(nèi)存區(qū)域。我建議直接把 vring 放在 reserved-memory 里并且地址按 64 字節(jié)或者 4KB 對齊。對齊問題后面會展開這里先記住不要把這些緩沖區(qū)定義在 M33 自己的 TCM 里因為 A35 訪問 TCM 的路徑和訪問 DDR 不同鏈路更慢還容易引發(fā) cache 問題。固件加載方式上官方 SDK 提供了一套 Yocto 工程也提供了預(yù)編譯的 Demo 固件。剛開始不需要自己從頭寫鏈接腳本直接基于官方例程改會更省事。但你必須把鏈接腳本里 RAM 區(qū)域的起始地址和 DTS 里的 reserved-memory 對應(yīng)起來否則固件能加載但運(yùn)行時立刻 HardFault。3. FreeRTOS在M33上的移植看著像M4實際上三處不一樣3.1 拿SDK的例程改還是從零移植STM32MP257 的 M33 完全可以直接跑 STM32Cube 系列的 HAL 庫。ST 官方提供的 OpenAMP 例程里M33 側(cè)工程一般用的是 CM33 內(nèi)核文件、HAL 驅(qū)動和 FreeRTOS 移植層。如果你熟悉 STM32F4/F7 的 CubeMX 工作流上手這個平臺并不難。但我不建議直接把老工程的 FreeRTOS 文件拷過來用。M33 和 M4 的底層差別不小TrustZone 會讓內(nèi)存和中斷分成安全/非安全兩組MPU 的單元數(shù)、內(nèi)存屬性配置也和 M4 不同部分外設(shè)的訪問權(quán)限要顯式打開。哪怕只是從 F4 拷貝一個port.c都可能因為底層匯編指令差異而編譯不過。比較好的路徑是先打開官方 M33 FreeRTOS 例程確認(rèn)能編譯能跑然后在此基礎(chǔ)上加入自己的任務(wù)、隊列和信號量。不要一開始就想著“我要寫一個最純凈的工程”在 MP257 上官方例程本身就是最可靠的地基。3.2 TrustZone帶來的隔離問題非安全態(tài)與安全態(tài)Cortex-M33 的 TrustZone 把整個系統(tǒng)劃分為安全世界和非安全世界。FreeRTOS 可以跑在安全態(tài)也可以跑在非安全態(tài)。ST 官方關(guān)于 M33 的 OpenAMP 例程通常讓 FreeRTOS 跑在非安全態(tài)因為這樣 Linux 側(cè)的 remoteproc 才能正常加載和調(diào)試固件。這帶來一個實際影響你在工程啟動文件里需要配置 SAUSecurity Attribution Unit把大部分外設(shè)和內(nèi)存區(qū)域標(biāo)記為非安全。否則非安全態(tài)的 FreeRTOS 一訪問外設(shè)寄存器立刻觸發(fā) bus error。我第一次調(diào)的時候GPIO 初始化明明沒寫錯但只要一碰GPIOA-MODER就進(jìn) HardFault查了半天才發(fā)現(xiàn)是 SAU 里完全沒有給外設(shè)開放非安全權(quán)限。如果項目里有安全需求可以把一部分邏輯放到安全側(cè)非安全側(cè)和 Linux 通信安全側(cè)負(fù)責(zé)校驗密鑰、管理關(guān)鍵數(shù)據(jù)。不過這會成倍增加開發(fā)復(fù)雜度。沒有強(qiáng)需求的話建議先用官方例程的默認(rèn)配置跑通再考慮 TrustZone 的安全隔離。3.3 中斷配置與SysTickMPU、NVIC和GIC的邊界M33 在裸機(jī) MCU 上用慣了會覺得 NVIC 是理所當(dāng)然的中斷控制器。但在 MP257 里系統(tǒng)級中斷有兩個層次M33 內(nèi)部有 NVIC同時芯片里還有一個 GIC負(fù)責(zé)把各種外設(shè)中斷統(tǒng)一發(fā)給 A35 或 M33。GIC 發(fā)給 M33 的中斷會以 SPIShared Peripheral Interrupt的形式進(jìn) NVIC。因此在配置外設(shè)中斷時你不僅在操作 NVIC還要確保 GIC 側(cè)已經(jīng)使能了這條中斷線。Linux 側(cè)的設(shè)備樹里可能會把某些外設(shè)中斷指定到 M33。如果兩邊的中斷路由配置不一致M33 就永遠(yuǎn)收不到中斷。FreeRTOS 的 SysTick 在 M33 上仍然用于系統(tǒng)節(jié)拍。默認(rèn)情況下SysTick 是內(nèi)核私有定時器不需要經(jīng)過 GIC。但要注意如果在低功耗模式下關(guān)閉了內(nèi)核時鐘SysTick 也會停擺導(dǎo)致 FreeRTOS 時間片失效。這個問題在“M33 側(cè)進(jìn)入 Stop 模式”的低功耗項目中特別明顯后面量產(chǎn)收尾部分再細(xì)說。3.4 堆棧與MPU給FreeRTOS任務(wù)畫好“安全圈”FreeRTOS 移植好之后第一件事不是急著跑 OpenAmp而是先把多個任務(wù)跑起來確認(rèn)調(diào)度器正常。任務(wù)棧大小設(shè)多少老手都會有自己的一套經(jīng)驗但在 M33 AMP 場景里任務(wù)棧和共享內(nèi)存之間會互相擠占所以需要更謹(jǐn)慎。建議打開 FreeRTOS 的堆棧溢出檢測功能至少用configCHECK_FOR_STACK_OVERFLOW 2。這個選項會在任務(wù)切換時主動檢查棧頂標(biāo)志能盡早發(fā)現(xiàn)棧溢出。我遇到過的情況是任務(wù)本身看起來沒炸但 OpenAmp 一端點在接收大包時遞歸調(diào)用了回調(diào)棧指針一路往下漲最后把另一個任務(wù)的棧踩了。MPU 的作用是把任務(wù)的內(nèi)存區(qū)域隔離開。M33 的 MPU 支持多個 region可以把每個任務(wù)棧設(shè)置成獨立 region并設(shè)置訪問權(quán)限。這個做法的代價是任務(wù)切換時 MPU 配置需要同步更新帶來額外性能開銷。我的建議是前期先用最簡單的方式把所有內(nèi)存權(quán)限都放開專心調(diào)試業(yè)務(wù)量產(chǎn)前再評估是否要用 MPU 做訪問保護(hù)。4. OpenAmp不是庫是套路RPMsg那條通道怎么修通的4.1 OpenAmp在M33側(cè)的角色不是操作系統(tǒng)的對立面OpenAmp 的全稱是 Open Asymmetric Multi-Processing它本身不是操作系統(tǒng)而是一套跨核通信框架。M33 側(cè)OpenAmp 庫像是一層“中間件”跑在 FreeRTOS 之上負(fù)責(zé)管理消息通道Linux 側(cè)內(nèi)核 remoteproc/rpmsg 子系統(tǒng)提供了對等驅(qū)動。兩邊用 RPMsgRemote Processor Messaging協(xié)議通信。很多人第一次接觸 RPMsg會把郵箱和共享內(nèi)存搞混。硬件郵箱是“敲門鈴”它只負(fù)責(zé)通知對方“我有數(shù)據(jù)了”本身不傳大數(shù)據(jù)。真正傳數(shù)據(jù)靠的是共享內(nèi)存里的 vring 和消息緩沖區(qū)。舉個例子A35 要給 M33 發(fā)一條 1KB 的控制指令實際流程是A35 把數(shù)據(jù)寫入共享內(nèi)存的某個 buffer 中然后寫 vring 的更新信息最后觸發(fā)一個硬件中斷給 M33M33 收到中斷后從對應(yīng)的 buffer 取出數(shù)據(jù)。M33 側(cè) OpenAmp 的初始化代碼官方例程里能看到類似這樣的流程解析 resource table拿到共享內(nèi)存地址和 vring 地址。調(diào)用openamp_init初始化遠(yuǎn)程處理器框架。注冊 RPMsg 端點和回調(diào)函數(shù)。等待 Linux 側(cè)啟動通信。這里的關(guān)鍵是不要試圖把 OpenAmp 和 FreeRTOS 割裂開。OpenAmp 的任務(wù)、中斷處理、接收回調(diào)都要集成到 FreeRTOS 的調(diào)度體系里。如果直接在中斷回調(diào)里處理大量數(shù)據(jù)M33 的實時任務(wù)會被嚴(yán)重拖延。4.2 共享內(nèi)存與vring郵箱和消息池是兩回事把共享內(nèi)存的布局設(shè)計好OpenAmp 就成功了一半。我習(xí)慣把共享區(qū)域分成兩層第一層是resource table里面保存了 vring 的描述信息以及各端點需要的共享緩沖。第二層是 vring 本身它由多個描述符組成每個描述符指向真正的數(shù)據(jù) buffer。一個常見問題是vring 的地址沒有在 DTS 和 resource table 之間保持一致。Linux remoteproc 驅(qū)動啟動 M33 時會從 resource table 讀 vring 地址再與 DTS 中的配置比對。如果兩邊對不上要么通信掛起要么握手失敗。不要相信“看起來差不多”的地址直接用十六進(jìn)制逐字節(jié)核對。還有一個容易被忽略的細(xì)節(jié)共享內(nèi)存區(qū)域的 cache 屬性。前文提到過no-map實際使用中還要明確這段內(nèi)存是配置成 cacheable 還是 non-cacheable。為了最簡單的穩(wěn)定性我通常把 vring 和共享 buffer 標(biāo)記為 non-cacheable。這樣省去了手動 cache 操作的復(fù)雜度代價是訪問共享內(nèi)存的速度稍慢。對于 RPMsg 這種小報文場景性能完全能接受。如果一定要用 cacheable就必須在每次發(fā)送前做 clean接收前做 invalidate否則會出現(xiàn)“對方明明寫了數(shù)據(jù)我卻讀到舊值”的問題。4.3 從Linux側(cè)發(fā)起通信rproc_boot與rpmsg_client_sampleLinux 側(cè)內(nèi)核的 remoteproc 子系統(tǒng)負(fù)責(zé)管理 M33 生命周期。啟動 M33echo start /sys/class/remoteproc/remoteproc0/state停止 M33echo stop /sys/class/remoteproc/remoteproc0/state啟動成功后Linux 下會多出一個/dev/rpmsg0設(shè)備節(jié)點。應(yīng)用程序可以像普通設(shè)備文件一樣打開它、讀寫數(shù)據(jù)。官方內(nèi)核里有一個rpmsg_client_sample模塊加載后會自動創(chuàng)建一個端點往 M33 發(fā)一條消息然后等待回應(yīng)。這個 Sample 是驗證整條鏈路最好的工具modprobe rpmsg_client_sample如果 M33 側(cè)的 FreeRTOS 例程已經(jīng)跑起來但rpmsg_client_sample沒反應(yīng)多半是 vring 地址不對、共享內(nèi)存 cache 配置不一致或者 M33 側(cè)根本沒有注冊對應(yīng)的服務(wù)端點。4.4 M33側(cè)循環(huán)收發(fā)拷貝策略與中斷回包M33 側(cè)收到 RPMsg 消息后回調(diào)函數(shù)會被 OpenAmp 庫調(diào)用。這個回調(diào)是在什么上下文里執(zhí)行的根據(jù)官方例程通常是在 OpenAmp 自己的接收任務(wù)里或者在一個由信箱中斷觸發(fā)的傘形中斷中。無論哪種都不應(yīng)該在里面做耗時操作。正確做法是回調(diào)函數(shù)里把數(shù)據(jù)拷貝到自己的任務(wù)緩沖然后通知業(yè)務(wù)任務(wù)去處理。這里有個取舍拷貝會帶來額外開銷但換來的是任務(wù)調(diào)度更加解耦。如果控制數(shù)據(jù)只有幾十字節(jié)拷貝幾乎可以忽略如果是大數(shù)據(jù)塊你也可以只拷貝指針但前提是發(fā)送方在收到 ACK 前不能重用這塊緩沖區(qū)。為了降低復(fù)雜度我初期一直是直接拷貝穩(wěn)定優(yōu)先。另外要注意M33 收到消息后如果需要回復(fù) Linux應(yīng)該在發(fā)送完成后調(diào)用一次緩存清理操作確保 Linux 能讀到最新數(shù)據(jù)。RPMsg 的發(fā)送函數(shù)rpm_send內(nèi)部一般會做必要的 cache 處理但如果你在回調(diào)里直接操作共享內(nèi)存還是要自己把關(guān)。5. 真機(jī)聯(lián)調(diào)階段踩過的坑每一個都值得記下來5.1 現(xiàn)象M33內(nèi)核崩潰但Linux毫無察覺第一次跑通 OpenAmp 后我給 M33 加了一個比較復(fù)雜的控制任務(wù)結(jié)果發(fā)現(xiàn) M33 側(cè)代碼進(jìn)入 HardFault但 Linux 側(cè)毫不知情。A35 的 remoteproc 驅(qū)動不會主動監(jiān)測 M33 是否還活著它只負(fù)責(zé)啟動和停止。M33 死了Linux 上的/dev/rpmsg0依然存在但收不到任何響應(yīng)。排查時我一開始以為是 FreeRTOS 里的任務(wù)棧溢出就把configCHECK_FOR_STACK_OVERFLOW打開也加了棧水印打印。后來發(fā)現(xiàn)問題出在一個定時器中斷服務(wù)函數(shù)里我在中斷里訪問了一處被 Linux 占用的外設(shè)寄存器M33 總線上直接報錯進(jìn)入 HardFault。這種問題最坑的地方在于M33 的 HardFault 如果不處理整個 M33 就“死寂”了而 Linux 側(cè)只能通過它的心跳超時才能發(fā)現(xiàn)。所以聯(lián)調(diào)初期M33 側(cè)一定要加上故障打印并且把 HardFault_Handler 里記錄的關(guān)鍵寄存器通過串口輸出。否則出了問題你根本不知道是任務(wù)調(diào)度崩了還是外設(shè)訪問違例。5.2 現(xiàn)象OpenAMP握手失敗rpmsg創(chuàng)建不了端點第二個坑是 OpenAmp 的握手失敗。Linux 側(cè)rpmsg_client_sample加載后/dev/rpmsg0雖然創(chuàng)建了但 M33 側(cè)一直沒有日志輸出也不回包。我一開始重新編譯了固件檢查了 endpoint 注冊順序問題依舊。后來用調(diào)試器掛在共享內(nèi)存上查看 resource table 的內(nèi)容才發(fā)現(xiàn) vring 地址和 DTS 里預(yù)設(shè)的地址差了幾百字節(jié)。原因是我改了鏈接腳本M33 固件里的 resource table 被編譯器重新排版了但 DTS 里的 reserved-memory 還是舊地址。兩邊各自都“對”就是互相不對。這里給新手一個建議不要手動修改 resource table 的存放位置除非你完全理解 OpenAmp 的加載流程。在任何一次鏈接腳本調(diào)整后都要重新生成 resource table并和設(shè)備樹比對。5.3 現(xiàn)象printf打印影響實時性M33 側(cè)調(diào)試時很多人習(xí)慣在任務(wù)里加 printf。這個思維是從 MCU 開發(fā)帶來的但在 MP257 上要特別小心。M33 的 printf 如果走串口而串口驅(qū)動在 FreeRTOS 里用了阻塞式發(fā)送遇到波特率 115200 時一條幾十字節(jié)的日志就要占掉幾毫秒。對于 20kHz 的控制周期這是災(zāi)難。我的做法是聯(lián)調(diào)階段把 printf 重定向到共享內(nèi)存里的一個環(huán)型日志區(qū)Linux 側(cè)隨時讀取。正式運(yùn)行階段把調(diào)試 printf 用宏關(guān)掉只保留錯誤級別日志。這樣既不影響實時性又能完整復(fù)現(xiàn)現(xiàn)場。5.4 調(diào)試手段用Linux的/dev/rpmsg0和M33的log互相印證AMP 聯(lián)調(diào)最大的痛苦是“兩邊都覺得對方?jīng)]發(fā)數(shù)據(jù)”。我的經(jīng)驗是建立一套雙向的“回環(huán)測試”再開始業(yè)務(wù)邏輯開發(fā)。先讓 M33 收到什么就回什么然后在 Linux 側(cè)寫一個簡單腳本往/dev/rpmsg0發(fā)一串遞增數(shù)據(jù)接收端校驗是否原樣返回。跑通回環(huán)后再逐步加入業(yè)務(wù)。如果回環(huán)都過不了問題一定在底層資源配置或緩存一致性上不要往下寫業(yè)務(wù)。M33 側(cè)也要把日志做成“有向心跳”每收到一條消息就通過串口輸出一個序號。這樣即使沒有調(diào)試器也能確認(rèn) OpenAmp 的接收鏈路是通的。我實測下來這套方法能過濾掉八成以上的“疑似通信問題”。6. 量產(chǎn)前必須補(bǔ)上的收尾工作6.1 監(jiān)控M33心跳光靠watchdog不夠M33 側(cè)跑 FreeRTOS通常都會開一個獨立看門狗防止任務(wù)死鎖。但看門狗只能“發(fā)現(xiàn)死機(jī)后復(fù)位”恢復(fù)后 Linux 側(cè)怎么知道 M33 已經(jīng)重啟過這是量產(chǎn)前必須設(shè)計的。我建議在 Linux 側(cè)寫一個應(yīng)用周期性通過 RPMsg 向 M33 發(fā)送心跳查詢M33 在最高優(yōu)先級任務(wù)里回應(yīng)。如果連續(xù)若干次沒有回應(yīng)Linux 主動stopstartM33。這樣 M33 即使崩潰也能在無人工介入的情況下自動恢復(fù)。注意這個機(jī)制不能依賴簡單的一問一答建議在心跳報文里帶序列號用于發(fā)現(xiàn) M33 是否發(fā)生過重啟。M33 側(cè)同樣要監(jiān)控 Linux 側(cè)的心跳。若 Linux 側(cè)卡死或者重啟M33 要能做安全保護(hù)比如把執(zhí)行機(jī)構(gòu)歸到安全位置。異構(gòu)系統(tǒng)不能只保護(hù)單側(cè)兩側(cè)都要有“對方可能死掉”的意識。6.2 低功耗時別忘了M33的電源域MP257 的功耗管理是個大話題A35 側(cè)的 Linux 有 CPUFreq、CPUIdleM33 側(cè)也有自己的低功耗模式。M33 進(jìn)入 Deep Sleep 前必須關(guān)閉對共享內(nèi)存的訪問并讓 Linux 側(cè)的 remoteproc 先處于停止?fàn)顟B(tài)。我踩過的坑是Linux 側(cè)進(jìn)入 suspendM33 還掛在共享內(nèi)存上結(jié)果喚醒后共享數(shù)據(jù)區(qū)出現(xiàn)撕裂。正確的順序是先讓 M33 進(jìn)入低功耗等待命令狀態(tài)再讓 Linux 進(jìn)入 suspend喚醒時反過來Linux 先恢復(fù)正常再喚醒 M33。整個流程要用 RPMsg 做一個握手協(xié)議不能用簡單延時“估摸”對方已經(jīng)完成。6.3 日志規(guī)范與遠(yuǎn)程升級的邊界M33 固件和 Linux 內(nèi)核是兩套獨立鏡像量產(chǎn)后的升級鏈路也完全不同。Linux 側(cè)可以通過 A/B 分區(qū)做系統(tǒng)級 OTAM33 固件則需要設(shè)計自己的升級機(jī)制常見做法是由 Linux 側(cè)把新固件下載到某個分區(qū)再通過 remoteproc 停止 M33、寫入新固件、重新啟動。升級過程中最怕兩件事一是升級到一半掉電M33 固件損壞二是新舊固件的資源表不兼容導(dǎo)致 OpenAmp 通信失敗。對第一個問題建議 M33 固件保留一個極小 Bootloader負(fù)責(zé)校驗 App 固件對第二個問題建議在 RPMsg 應(yīng)用層約定版本號Linux 啟動 M33 后先做版本握手版本不匹配直接拒絕業(yè)務(wù)。這些在項目初期就要定好量產(chǎn)后再改協(xié)議非常痛苦。6.4 實測性能參考與后續(xù)擴(kuò)展拿我們實際項目的數(shù)據(jù)做個參考A35 雙核跑 LinuxM33 跑 FreeRTOSOpenAmp 通過 RPMsg 每 1ms 雙向交換一條 64 字節(jié)狀態(tài)幀。M33 側(cè)額外跑著三個任務(wù)分別是 1kHz 控制循環(huán)、按鍵掃描、串口日志。整條鏈路跑下來RPMsg 單次收發(fā)的 CPU 占用和中斷延遲都在可接受范圍內(nèi)。如果業(yè)務(wù)需要更大帶寬可以考慮把共享緩沖區(qū)加大或使用帶 cache 的訪問模式但務(wù)必做好緩存一致性處理。后續(xù)擴(kuò)展方向上可以考慮讓 M33 直接承擔(dān)一部分傳感器數(shù)據(jù)預(yù)處理只把提煉后的結(jié)果發(fā)給 A35。也可以嘗試把部分網(wǎng)絡(luò)協(xié)議棧卸載到 Linux把實時安全策略放在 M33。這個平臺最大的魅力就在于此兩顆核各司其職又共用一套內(nèi)存。對我個人而言用過 MP257 的 M33 FreeRTOS OpenAmp 組合后再回到“外掛 MCU 串口”的老路確實回不去了。