438
大家好，我是痞子衡，是正經(jīng)搞技術(shù)的痞子。今天痞子衡給大家分享的是為i.MXRT1060更換較大容量Flash導(dǎo)致二級App異常啟動(dòng)問題。
痞子衡最近在支持一個(gè) RT1062 國外客戶項(xiàng)目，客戶在項(xiàng)目預(yù)研階段為 RT1062 搭配的啟動(dòng) Flash 是較小容量 IS25LP064A，接近量產(chǎn)的時(shí)候需要改用較大容量 IS25LP128F?？蛻舯疽詾橹皇且粋€(gè)簡單的同廠家同系列 Flash 容量小升級而已，誰知道竟然遇到奇怪的芯片啟動(dòng)問題！在痞子衡和客戶一番溝通之后，認(rèn)定確實(shí)是個(gè)非常奇怪的案例，且聽痞子衡慢慢道來：
本篇是上篇，主要是拋出問題，希望大家能夠留言積極回復(fù)，給出你認(rèn)為出問題的地方。
一、問題描述
客戶項(xiàng)目代碼分為兩個(gè)部分，一個(gè)是從 0x6000_2000 處開始鏈接的 L2 Boot，還有一個(gè)是 0x6040_0000 處開始鏈接的 App，RT1062 芯片上電 BootROM 加載 L2 Boot 運(yùn)行，L2 Boot 再跳轉(zhuǎn)到 App 執(zhí)行。
客戶首先在小容量 IS25LP064A 上通過了代碼測試，借助恩智浦官方下載工具?MCUXpresso SEC Secure Provisioning Tool?(當(dāng)然這里痞子衡更推薦的是?NXP-MCUBootUtility)，先燒寫 App，再燒寫 L2 Boot（因?yàn)?App 由 L2 Boot 直接引導(dǎo)執(zhí)行，所以其無需 RT 啟動(dòng)頭，即使后下載的 L2 Boot 啟動(dòng)頭會(huì)覆蓋先下載的 App 啟動(dòng)頭也無關(guān)緊要）。
客戶最終希望能給 L2 boot 做簽名啟動(dòng)，App 無需簽名，所以 RT1062 內(nèi)部 fuse SEC_CONFIG[1:0] 需要被燒寫成 2'b1x - HAB Closed?？蛻敉瑫r(shí)做了兩種測試，L2 boot 無簽名情況以及有簽名情況，均正常工作，因此可以證明當(dāng)前 L2 Boot 和 App 代碼設(shè)計(jì)在 IS25LP064A 上跑一切正常，也和是否簽名無關(guān)（RT1062 HAB 狀態(tài)）。
然后客戶換了一塊新板子，上面放置得是大容量 IS25LP128F，程序無任何改動(dòng)，下載流程也一樣，在 L2 Boot 無簽名的時(shí)候，也能夠正常工作。但是一旦給 L2 Boot 加了簽名，這時(shí)候 L2 Boot 能夠正常啟動(dòng)（有 Log 打出），但是 App 卻沒有正常啟動(dòng)（無 Log 輸出），并且從 Log 輸出來看，L2 Boot 一直在重復(fù)啟動(dòng)。
看到這你的第一反應(yīng)是什么？根據(jù)控制變量法，似乎問題是由換到 IS25LP128F 引起的，也似乎是 L2 Boot 加了簽名引起的。但是客戶之前的測試能夠證明，單獨(dú)改動(dòng)這兩個(gè) X 因素之一并不會(huì)導(dǎo)致問題，然而合在一起就引發(fā)了問題。
二、現(xiàn)有測試與分析
目前客戶暫未分享其項(xiàng)目代碼給痞子衡，為了快速驗(yàn)證客戶這種情況，痞子衡在恩智浦開發(fā)板 RT1060-EVKC 上做了類似測試，在 SDK_24_12_00_MIMXRT1060-EVKCboardsevkcmimxrt1060demo_appshello_world 例程基礎(chǔ)上（flexspi_nor_debug） 上創(chuàng)建了兩個(gè) target，一個(gè)是 flexspi_nor_boot（增加 app 跳轉(zhuǎn)代碼），另一個(gè) flexspi_nor_app（去掉 BOOT_HEADER，然后修改鏈接地址到 0x6040_0000）。
- 測試代碼地址： https://github.com/JayHeng/func-rt1060-flexspi-minimal-boot-and-app
分別編譯出 Mini L2 Boot 和 Mini App 之后，按照客戶同樣下載流程（用 SEC 上位機(jī)，且使能簽名），這是痞子衡第一次用官方 SEC 上位機(jī)做簽名下載操作，使用體驗(yàn)總體不如 NXP-MCUBootUtility 來得順手。
痞子衡先在默認(rèn) W25Q128JWSIQ 上做了測試，然后又將板子上的 Flash 換成了 IS25LP128F 做了同樣測試。讓痞子衡感到遺憾的是，并未復(fù)現(xiàn)客戶的情況，Mini L2 Boot 和 Mini App 跑得穩(wěn)如狗。
三、值得關(guān)注的點(diǎn)
雖然沒能成功復(fù)現(xiàn)客戶的問題，但是在檢查客戶使用的兩顆 Flash 的數(shù)據(jù)手冊時(shí)，還是發(fā)現(xiàn)了一些隱患點(diǎn)的。我們先來看一下恩智浦官方開發(fā)板 Flash 使用情況以及 SDK 里對 Flash XIP 啟動(dòng)的速度配置（所謂 FCB，SDK_XXX_MIMXRT1xxx-EVKboardsevkmimxrt1xxxxipevkmimxrt1xxx_flexspi_nor_config.c），從 SDK 2.15 開始 FCB 嘗試為支持調(diào)整 dummy cycle 的 Flash 做了適配以跑到 Flash 的最高速度。
Note：不了解 dummy cycle 可以先閱讀痞子衡舊文 《在i.MXRT啟動(dòng)頭FDCB里調(diào)整Flash工作頻率也需同步設(shè)Dummy Cycle (以IS25WP128為例)》
然而在 RT1060 SDK 里的 FCB 并沒有加入 dummy cycle 方面的考慮，直接就是用了默認(rèn) 6 dummy cycle 來支持 120MHz SDR Quad Fast Read (0xEB) 性能，這對于 RT1060-EVK/EVKB 上的 IS25WP064AJBLE 來說其實(shí)是有隱患的（對應(yīng)默認(rèn)最高頻率是 104MHz），算超頻在跑了。
此外痞子衡舊文?《同一廠商不同系列Flash型號下Dummy Cycle設(shè)置方法可能有差異 (以IS25LP064A為例)》?里介紹了 IS25LP064A 和 IS25WP128 系列有差異，用相同的分析方法你會(huì)發(fā)現(xiàn) IS25LP064A 和 IS25LP128F 一樣有差異，雖然 IS25LP128F 上限可以跑到 166MHz，但是默認(rèn) 6 dummy cycle 下僅支持 81MHz。
客戶包括痞子衡都直接使用得 SEC 上位機(jī)工具自動(dòng)生成的 FCB 頭，其只能使用默認(rèn) 6 dummy cycle，而我們都將 Flash 運(yùn)行頻率設(shè)到了 120MHz 以上，這顯然是有隱患的（雖然痞子衡的 Mini L2 Boot/App 沒有跑出問題，但是壓力運(yùn)行之下可靠性無法保證）。
這會(huì)是客戶問題的答案嗎？痞子衡讓客戶將 Flash 工作頻率調(diào)到了 80MHz 以符合手冊要求，但是客戶反饋，問題仍然存在！目前為止，痞子衡暫無其它思路，你能想到可能出問題的地方嗎？
