前端時間回來了一塊板子，于是各個團隊都進入了緊張的 Bringup 工作中。

這塊板子上的主芯片是一顆 Arm Cortex M3 + DSP 的異構芯片，結構大概是這樣的：

CM3 和 DSP 的固件獨立存儲在 Flash 中，上電后 CM3 先啟動，然后 CM3 再把 DSP 的固件從 Flash 中加載到 Sram 中，最后再從 Sram 中拷貝到 DSP 的 ITCM 中，至于為什么不繞過 Sram 直接把 DSP 的固件從 Flash 中讀到 DSP 的 ITCM 中，我們這里先不討論。

Bringup 進行到第二天的時候，負責 DSP 的同學反饋說，DSP 的程序加載上去后，始終不能正常運行 —— 觀察不到任何正常啟動的現象。其實在 Bringup 剛開始階段，這種情況是經常遇到的，我第一反應就是，讓這位同學連上 DSP 的 JTAG 去單步調試，看到底發生了什么。

第三天的時候，我又找這位同學問了下，現在是什么情況了，這位同學一臉茫然的說：好奇怪，如果用 DSP 的 JTAG 直接下載固件到 ITCM，就能正常運行，通過 Cortex M3 去加載，就不能正常運行。聽到這個差別，我潛意識的問他：有沒有確認過 CM3 加載到 ITCM 中的固件是否正常？這位同學說應該不會有問題，這套流程他們之前在其他平臺上都驗證過。他們還有一些其他的壞一點，準備優先就他們的懷疑點做一些實驗排查，比如 DSP 的cache 啊，復位控制啊，PLL 頻率啊什么的。

因為 Bringup 階段事情比較多，我也就沒在追究去忙其他的事情了。

第四天，說所有懷疑的實驗都做完了，還是沒進展。我說確認下 CM3 拷貝到 ITCM 里面的固件是否正常吧 —— CM3 把固件拷貝到 ITCM 后，在用 JTAG 讀出來，然后對比。

實驗做完，這位同學蔫蔫的說，從 ITCM 中讀出來的固件數據和編譯出來的固件數據有一小部分對不上。而且這部分對上的數據位于固件尾巴上。

固件加載出錯，程序肯定無法正常運行！那就直接排查數據在哪個環節出錯的吧！

固件從 Flash 中加載到 Sram 中后，也用 JTAG 讀出來和原始數據對比，結果正常！

那就是從 Sram 到 ITCM 的這個環節處了問題！

查看這段拷貝的代碼，原來就是一個 rt_memcpy —— 我們在 Cortex M3 上運行的是 RT-Thread。

這位同學用 JLink 單步跟蹤這段代碼發現，每次程序運行到第二部分的時候，拷貝就異常了，能看到程序執行了，但是數據就是沒拷貝過去！而第一段的拷貝都是正常的。

事出異常必有妖，我決定反匯編看看這段代碼后面藏了什么玄機。

果真有貓膩，第一段代碼，對于大塊的 4 字節對齊的數據，CPU 是以 STR 這樣的指令超 ITCM 寫數據，即以 Word 為單位訪問 ITCM，對于第二段，也就是一段數據的尾巴，剩下的那些零零散的不夠四字節的數據，CPU 是以 STRB 這樣的指令超 ITCM 寫數據，即以字節為單位訪問 ITCM。

memcpy 這樣寫是為了提高數據搬運的效率。對于按照 Word 對齊的數據，以 Word 的模式搬運，對于剩下的非Word 對齊的數據，以 Byte 模式搬運，一次搬運四字節肯定比一次搬運一字節要快。

但是我們這里踩了什么坑呢？以 Word 方式訪問 ITCM 就正常，以 Byte 的方式訪問就不成功？

為了進一步確認這個結論，我寫了一段測試代碼：

這段測試代碼構造了一個 memcpy 命令，我可以在命令行通過 memcpy cnt value 來控制每次超 ITCM 搬運不同長度的數據，下面就開始測試：

一次寫 16 字節的 1 到 ITCM，然后通過 Jlink 可以看到 ITCM 這片區域被成功的寫入了 16 字節的 1。因為 16 是 4 個 4 字節，所以這次的 memcpy 是通過 STR 指令進行的。

一次 copy 17 字節的 2 到 ITCM， 通過 JLink 觀察右下角的 ITCM，發現只寫進去了 16 字節。根據 memcpy 算法，前 16 字節 是以 Word 的形式通過 STR 指令寫入 ITCM 的，剩下的 一 字節 是以 STRB 的形式寫入 ITCM 的。

一次 Copy 18 字節，同樣發現只寫進去了 16 字節。

一次 Copy 19 字節，還是只寫進去了 16 字節！

一次 Copy 20 字節，全部寫入成功了！按照 memcpy 算法，20 字節是以 五次 STR 指令，以 Word 模式拷貝過去的。

一次 Copy 21 字節，發現還是只寫入了 20 字節！

一次 Copy 24 字節，全部拷貝成功！

到這里，我基本確認 Cortex M3 以 Byte 模式訪問 ITCM 會失敗！

然后聯系 IC 設計方，確認是什么原因。IC 設計方回復說：Cortex M3 確實無法以 Byte 模式訪問 ITCM，這是總線設計上限制的！

艾瑪呀！忽然有種想打人的沖動，你文檔上根本沒提有這個限制啊！

后來想想，在無數次的 Bringup 過程中，類似這種固件拷貝不完整的情況，似乎坑過我好幾次，有一次 Linux 內核起來后，很多驅動都加載失敗，我一路從 Linux Kernel 查找到 U-Boot，再查到下載，最后確認是固件下載工具有問題，DTB 沒有下載完整，而且這尼瑪也是因為 flash 扇區對齊的問題導致的！還有一次從 U-Boot SPL 跳到 Arm turst firmware 后，總是卡死固定的位置，然后 Dump 發現 ATF 固件加載不完整，最后確認是 CLK 驅動問題引起 eMMC 工作異常導致的。