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