大家好，我是痞子衡，是正經搞技術的痞子。今天痞子衡給大家介紹的是一種快速定位i.MXRT600闆級設計ISP[2-0]啟動模式引腳上電時序問題的方法。
我們知道恩智浦i.MXRT600是主打音頻市場的MCU産品，其也是i.MXRT三位數平台的第一款型号。這顆MCU已被衆多知名國際大廠客戶選用，在項目中作為協處理器負責音頻相關子功能。不少客戶都已經到了量産階段，最近痞子衡在支援其中一個量産客戶，客戶遇到了同一批次某幾個闆卡無法正常啟動的問題。痞子衡和同僚一起排查，最終發現是ISP[2:0]啟動引腳電平上電時序問題。這其實是個典型問題，痞子衡今天教你一招快速定位此類問題的方法：
我們先來看看客戶的問題，下面是客戶闆卡簡圖，i.MXRT600是負責音頻功能的協處理器，它的啟動引腳ISP[2:0]與主應用處理器(AP)連接配接了起來（客戶項目設計裡，AP并不負責控制i.MXRT600的啟動模式），為了防止對i.MXRT600上電ISP引腳采樣有影響，客戶還特地在中間加了一層反向隔離電路。
注：其實i.MXRT600支援Serial Boot模式，這種模式下i.MXRT600作為協處理器，其應用程式資料可直接由AP通過指定的UART/I2C/SPI/USB下載下傳進i.MXRT600的内部RAM運作，能省去一顆外部Flash。
客戶量産過程中，同一批次幾百塊闆卡，有一兩塊闆卡上i.MXRT600無法啟動。客戶做了少量ABA實驗：将無法啟動闆卡上的i.MXRT600晶片吹下來，換到能正常啟動闆卡上，依然無法啟動。反過來，能正常啟動闆卡上的i.MXRT600晶片換到無法正常啟動的闆卡上，這塊闆卡就能正常啟動了。
從上面ABA實驗來看，似乎不是闆級設計問題，像是出問題的闆卡上i.MXRT600晶片自身問題。痞子衡拿到一塊出問題的闆子，上電後測量了ISP[2:0]引腳電平，其值是3'b011 - FlexSPI Boot from Port A，上電穩定後ISP設定是沒問題的，但剛上電時i.MXRT600 BootROM到底采樣到的是什麼ISP電平值沒人知道。
下面是客戶闆卡上ISP部分反向隔離設計，為了驗證是ISP采樣時機問題，我們特意對電路進行改造将RT600_BOOT0和RT600_BOOT2分别強行拉高和拉低，然後給闆卡重新上電，終于闆卡能正常啟動了。
是以我們可以得出初步結論，對于i.MXRT600從上電到BootROM進行ISP采樣，這段時間不是一個嚴格固定值，因晶片制造差異，這個時間應該是在一定範圍内，闆級供電設計時上電時間應留有足夠餘量。客戶這個項目裡上電時間餘量留得不足，導緻無法滿足個别i.MXRT600晶片ISP采樣時間要求。
在介紹快速定位ISP采樣時機問題方法前，痞子衡先帶大家了解下i.MXRT600 BootROM中關于啟動模式的處理流程。
咱們先回顧下痞子衡的舊文 《Boot配置(ISP_Pin/OTP)》，每次i.MXRT600晶片硬複位，OTP中的部分關于系統配置的值會被自動加載到OCOTP子產品相應Shadow Register裡（關于OCOTP外設基礎知識可參考 《OTP及其燒寫方法》），BootROM中主要用如下 get_runtime_boot_device_info() 函數來擷取最終啟動模式，并将其存在全局變量 s_bootDeviceInfo 中。
注：代碼中 OCOTP->OTP_SHADOW[0x60] 寄存器低四位即晶片參考手冊裡提及的 PRIMARY_BOOT_SRC[3:0]
每一次i.MXRT600系統軟複位去重新執行BootROM時，ISP[2:0]引腳狀态都會被重新采樣，這完全是軟體采樣。ROM中ISP采樣功能函數如下面 get_bootpin_mode() 所示，代碼中做了IO電平去抖處理：
上面就是BootROM中關于啟動模式的處理代碼。那麼有沒有方法挂上調試器通過查後門方式直接讀取到 s_bootDeviceInfo 變量值呢？很抱歉，不可以！即使痞子衡也做不到，雖然痞子衡能通過查BootROM map檔案得知這個變量放在 0x10012d38 位址處。但是i.MXRT600 BootROM中內建了 《Debug Mailbox機制》，我們無法通過調試器讀取正常運作後的ROM狀态，這條路行不通。
第一小節介紹的客戶項目啟動問題，其實還算比較好定位，因為有ABA實驗在先，基本可以明确問題就出在ISP采樣時機上。但更多時候，在客戶項目研發階段，沒有ABA實驗的條件，可能僅有一塊闆卡，并且Flash配置以及App裡啟動頭是否正确都尚待驗證。這種情況下，我們就需要一種快速甄别是否是ISP采樣時機因素導緻的啟動問題。
當晶片無法啟動時，我們第一想法肯定是要得知第二小節介紹裡 s_bootDeviceInfo 到底是什麼值，這樣我們就能反推ISP引腳到底在ROM裡是什麼采樣值，但這條路行不通。換個角度想，我們能不能不讓BootROM去采樣ISP引腳，換一種替代方式來決定啟動模式，如果這種情況下能按替代設定去啟動，就也可以反證ISP引腳采樣時機有問題。
這種啟動模式替代設定方法就是痞子衡今天要教大家的方法，利用調試器臨時改寫OCOTP->OTP_SHADOW[0x60]值（對的，我們可以不燒寫OTP），改寫完成後對晶片做一次軟複位即可。OCOTP->OTP_SHADOW寄存器組僅晶片硬體複位或者執行OCOTP更新指令其值才會被重新加載，軟複位不會影響其值。
讓我們在MIMXRT685-EVK上做一次實驗，這塊闆卡上Flash連到了FlexSPI0 Port B上，我們随意下載下傳一個SDK XIP工程，并将ISP引腳撥碼設為3'b010 - FlexSPI Boot from Port B，複位後晶片能正常啟動，工程運作正常。
現在我們将ISP引腳撥碼設為3'b110 - Serial ISP，軟複位後晶片進入了ISP下載下傳模式，不會從Flash啟動。查晶片頭檔案得知 OCOTP->OTP_SHADOW[0x60] 寄存器位址是 0x50130180，我們現在嘗試改寫這個寄存器。
挂上J-Link調試器，打開J-Link Commander，連接配接晶片，注意選擇"MIMXRT685_M33"，然後使用w4指令在0x50130180位址處寫入0x00000005（在PRIMARY_BOOT_SRC[3:0]定義裡，4'b0101是QSPI_B_BOOT）。
繼續執行reset和go指令（或者按一下闆載軟複位按鈕RESET BUTTON SW3），這時候你可以看到晶片從Flash正常啟動了，SDK XIP工程又運作起來了，顯然這時候ISP引腳電平設定被忽略了，是以我們找到了有效的啟動模式替代設定方法。
最後有一點要注意，在使用J-Link軟複位時，如果看到如下log，得檢查下配套JLinkScript裡的ResetTarget()函數具體功能，要確定核心真的被複位了。
至此，快速定位i.MXRT600闆級設計ISP[2-0]啟動模式引腳上電時序問題的方法痞子衡便介紹完畢了，掌聲在哪裡~~~
文章會同時釋出到我的 部落格園首頁、CSDN首頁、知乎首頁、微信公衆号 平台上。
微信搜尋"痞子衡嵌入式"或者掃描下面二維碼，就可以在手機上第一時間看了哦。
最後歡迎關注痞子衡個人微信公衆号【痞子衡嵌入式】，一個專注嵌入式技術的公衆号，跟着痞子衡一起玩轉嵌入式。
衡傑(痞子衡)，目前就職于恩智浦MCU系統部門，擔任嵌入式系統應用工程師。
專欄内所有文章的轉載請注明出處：http://www.cnblogs.com/henjay724/
與痞子衡進一步交流或咨詢業務合作請發郵件至 [email protected]
可以關注痞子衡的Github首頁 https://github.com/JayHeng，有很多好玩的嵌入式項目。
關于專欄文章有任何疑問請直接在部落格下面留言，痞子衡會及時回複免費(劃重點)答疑。
痞子衡郵箱已被私信擠爆，技術問題不推薦私信，堅持私信請先掃碼付款(5元起步)再發。