大家好，我是痞子衡，是正經搞技術的痞子。今天痞子衡給大家分享的是為i.MXRT1060更換較大容量Flash導致二級App異常啟動問題。

痞子衡最近在支持一個 RT1062 國外客戶項目，客戶在項目預研階段為 RT1062 搭配的啟動 Flash 是較小容量 IS25LP064A，接近量產的時候需要改用較大容量 IS25LP128F?？蛻舯疽詾橹皇且粋€簡單的同廠家同系列 Flash 容量小升級而已，誰知道竟然遇到奇怪的芯片啟動問題！在痞子衡和客戶一番溝通之后，認定確實是個非常奇怪的案例，且聽痞子衡慢慢道來：

本篇是上篇，主要是拋出問題，希望大家能夠留言積極回復，給出你認為出問題的地方。

一、問題描述

客戶項目代碼分為兩個部分，一個是從 0x6000_2000 處開始鏈接的 L2 Boot，還有一個是 0x6040_0000 處開始鏈接的 App，RT1062 芯片上電 BootROM 加載 L2 Boot 運行，L2 Boot 再跳轉到 App 執行。

客戶首先在小容量 IS25LP064A 上通過了代碼測試，借助恩智浦官方下載工具 MCUXpresso SEC Secure Provisioning Tool (當然這里痞子衡更推薦的是 NXP-MCUBootUtility)，先燒寫 App，再燒寫 L2 Boot（因為 App 由 L2 Boot 直接引導執行，所以其無需 RT 啟動頭，即使后下載的 L2 Boot 啟動頭會覆蓋先下載的 App 啟動頭也無關緊要）。

客戶最終希望能給 L2 boot 做簽名啟動，App 無需簽名，所以 RT1062 內部 fuse SEC_CONFIG[1:0] 需要被燒寫成 2'b1x - HAB Closed?？蛻敉瑫r做了兩種測試，L2 boot 無簽名情況以及有簽名情況，均正常工作，因此可以證明當前 L2 Boot 和 App 代碼設計在 IS25LP064A 上跑一切正常，也和是否簽名無關（RT1062 HAB 狀態）。

然后客戶換了一塊新板子，上面放置得是大容量 IS25LP128F，程序無任何改動，下載流程也一樣，在 L2 Boot 無簽名的時候，也能夠正常工作。但是一旦給 L2 Boot 加了簽名，這時候 L2 Boot 能夠正常啟動（有 Log 打出），但是 App 卻沒有正常啟動（無 Log 輸出），并且從 Log 輸出來看，L2 Boot 一直在重復啟動。

看到這你的第一反應是什么？根據控制變量法，似乎問題是由換到 IS25LP128F 引起的，也似乎是 L2 Boot 加了簽名引起的。但是客戶之前的測試能夠證明，單獨改動這兩個 X 因素之一并不會導致問題，然而合在一起就引發了問題。

二、現有測試與分析

目前客戶暫未分享其項目代碼給痞子衡，為了快速驗證客戶這種情況，痞子衡在恩智浦開發板 RT1060-EVKC 上做了類似測試，在 \SDK_24_12_00_MIMXRT1060-EVKC\boards\evkcmimxrt1060\demo_apps\hello_world 例程基礎上（flexspi_nor_debug） 上創建了兩個 target，一個是 flexspi_nor_boot（增加 app 跳轉代碼），另一個 flexspi_nor_app（去掉 BOOT_HEADER，然后修改鏈接地址到 0x6040_0000）。

測試代碼地址： https://github.com/JayHeng/func-rt1060-flexspi-minimal-boot-and-app

分別編譯出 Mini L2 Boot 和 Mini App 之后，按照客戶同樣下載流程（用 SEC 上位機，且使能簽名），這是痞子衡第一次用官方 SEC 上位機做簽名下載操作，使用體驗總體不如 NXP-MCUBootUtility 來得順手。

痞子衡先在默認 W25Q128JWSIQ 上做了測試，然后又將板子上的 Flash 換成了 IS25LP128F 做了同樣測試。讓痞子衡感到遺憾的是，并未復現客戶的情況，Mini L2 Boot 和 Mini App 跑得穩如狗。

三、值得關注的點

雖然沒能成功復現客戶的問題，但是在檢查客戶使用的兩顆 Flash 的數據手冊時，還是發現了一些隱患點的。我們先來看一下恩智浦官方開發板 Flash 使用情況以及 SDK 里對 Flash XIP 啟動的速度配置（所謂 FCB，\SDK_XXX_MIMXRT1xxx-EVK\boards\evkmimxrt1xxx\xip\evkmimxrt1xxx_flexspi_nor_config.c），從 SDK 2.15 開始 FCB 嘗試為支持調整 dummy cycle 的 Flash 做了適配以跑到 Flash 的最高速度。

Note：不了解 dummy cycle 可以先閱讀痞子衡舊文 《在i.MXRT啟動頭FDCB里調整Flash工作頻率也需同步設Dummy Cycle (以IS25WP128為例)》

然而在 RT1060 SDK 里的 FCB 并沒有加入 dummy cycle 方面的考慮，直接就是用了默認 6 dummy cycle 來支持 120MHz SDR Quad Fast Read (0xEB) 性能，這對于 RT1060-EVK/EVKB 上的 IS25WP064AJBLE 來說其實是有隱患的（對應默認最高頻率是 104MHz），算超頻在跑了。

此外痞子衡舊文 《同一廠商不同系列Flash型號下Dummy Cycle設置方法可能有差異 (以IS25LP064A為例)》 里介紹了 IS25LP064A 和 IS25WP128 系列有差異，用相同的分析方法你會發現 IS25LP064A 和 IS25LP128F 一樣有差異，雖然 IS25LP128F 上限可以跑到 166MHz，但是默認 6 dummy cycle 下僅支持 81MHz。

客戶包括痞子衡都直接使用得 SEC 上位機工具自動生成的 FCB 頭，其只能使用默認 6 dummy cycle，而我們都將 Flash 運行頻率設到了 120MHz 以上，這顯然是有隱患的（雖然痞子衡的 Mini L2 Boot/App 沒有跑出問題，但是壓力運行之下可靠性無法保證）。

這會是客戶問題的答案嗎？痞子衡讓客戶將 Flash 工作頻率調到了 80MHz 以符合手冊要求，但是客戶反饋，問題仍然存在！目前為止，痞子衡暫無其它思路，你能想到可能出問題的地方嗎？