不確定性排查：PSRAM、NOR Flash與USB實戰(zhàn)經(jīng)驗)
做嵌入式這幾年P(guān)SRAM、NOR Flash、USB這三個名字我?guī)缀跆焯齑蚪坏馈Ｒ粋€是內(nèi)存擴展一個是代碼與參數(shù)的存放地一個是和外部世界通信的接口——聽起來都是再標準不過的外設(shè)?？烧嬲阉鼈兘M合在一個系統(tǒng)里跑穩(wěn)定尤其是要在量產(chǎn)線上批量復(fù)現(xiàn)時你會發(fā)現(xiàn)不確定性這三個字幾乎無處不在。同一顆芯片、同一份代碼有的板子一次過有的板子偶發(fā)枚舉失敗有的設(shè)備低溫下代碼加載直接卡死。這不是玄學(xué)而是這三類器件在物理層和協(xié)議層本身就帶著一批說不準的行為工程上如果不去理解這些不確定性就會在排障時走很多彎路。這篇文章把我這些年調(diào)PSRAM、NOR Flash、USB時踩過的坑、驗證過的方法和最終沉淀下來的排查套路一次性整理出來適合正在做MCU/嵌入式Linux產(chǎn)品方案的工程師也適合剛?cè)胧諷TM32、ESP32等平臺、被外設(shè)穩(wěn)定性問題折磨的新手。內(nèi)容不追求面面俱到重點是把為什么會出現(xiàn)不確定性和怎么把它管住講透看完你至少能少熬夜調(diào)幾個Bug。1. 一個翻車現(xiàn)場引出的三個不確定性1.1 項目背景PSRAM、NOR Flash、USB為什么會湊到一起先還原一下我經(jīng)歷過的一個典型場景。某款帶屏的IoT產(chǎn)品主控選了帶PSRAM擴展的MCU方案PSRAM用來跑UI緩沖和音頻緩沖固件放在一顆8MB的NOR Flash里上電后由Bootloader從Flash搬運到內(nèi)部SRAM/PSRAM執(zhí)行同時設(shè)備通過USB Device接口連接電腦既要做USB虛擬串口CDC做日志輸出還要支持DFU固件升級。這個組合在今天其實非常常見。PSRAM解決內(nèi)存不夠用NOR Flash解決代碼和參數(shù)怎么可靠存放USB解決怎么跟PC交互。三者看似各管一攤但在實際調(diào)試中它們會互相作用USB枚舉瞬間的電流波動能干擾PSRAM的供電NOR Flash擦除時被USB的中斷打斷可能導(dǎo)致擦除流程異常PSRAM初始化沒完成時USB描述符中斷來了系統(tǒng)直接死機。要理清這些就得先把每一類器件的不確定性單獨拿出來看。1.2 所謂不確定性到底指的是什么我理解的不確定性不是量子力學(xué)那種真隨機而是指器件的某個行為在datasheet的典型條件下是確定的但在真實系統(tǒng)里因為供電、溫度、時序、代碼順序、總線復(fù)用等原因結(jié)果變得難以預(yù)測。具體分四類時序不確定性上電穩(wěn)定時間、指令間隔、擦寫完成時間都有最小/最大范圍超時和欠時都可能出錯。電氣不確定性信號沿的抖動、電源紋波、PCB寄生參數(shù)、線纜阻抗等會讓數(shù)據(jù)采樣點在臨界區(qū)浮動。協(xié)議狀態(tài)不確定性USB枚舉、Flash狀態(tài)機、PSRAM刷新等都有內(nèi)部狀態(tài)外部事件如中斷、掉電切入時狀態(tài)機會落在不可預(yù)期的位置。上下文不確定性同樣的代碼在不同主頻、不同編譯器優(yōu)化等級、不同GPIO初始化順序下行為不同。這類最坑因為復(fù)現(xiàn)困難。這四類不確定性的背后是物理和協(xié)議的復(fù)雜機制。后面三章我會逐個拆解并且給出實操層面的管住它們的辦法。2. PSRAM的藏著掖著刷新與時序的不確定性2.1 先說原理PSRAM為什么叫偽SRAMPSRAMPseudo SRAM偽靜態(tài)隨機存儲器的存儲核心其實是DRAM只是外部接口做成了SRAM的樣子。你不需要像用SDRAM那樣去管理行激活、預(yù)充電、刷新這些細節(jié)直接像SRAM一樣讀寫就行。代價是芯片內(nèi)部有一個隱藏的刷新邏輯它會周期性對存儲單元做刷新。這個刷新過程對使用者來說是不可見的但它會對總線的可用帶寬產(chǎn)生影響。某些時候你讀一個地址正好碰上內(nèi)部刷新周期返回數(shù)據(jù)的延遲就會比平時大一點。這就是PSRAM第一個不確定性的來源——訪問延遲不是恒定值。另一個層面SPI接口的PSRAM比如APS6404、LY68L6400、IPS6404在MCU項目里用得越來越多。它的好處是引腳少、布線簡單但代價是協(xié)議里引入了等待周期Latency的概念。讀操作發(fā)出命令后數(shù)據(jù)并不會立刻出現(xiàn)在MOSI上而是要等若干個dummy cycle。這個dummy cycle的數(shù)量又跟工作頻率、指令模式、芯片配置有關(guān)。配置錯了要么讀到全0要么數(shù)據(jù)錯位而且不同廠家的芯片行為還不完全一樣非常容易出問題。2.2 初始化與讀寫時最容易踩的時序坑SPI PSRAM的初始化一般分幾步上電等待VCC穩(wěn)定至少幾百微秒到1ms具體看型號、發(fā)送復(fù)位命令、發(fā)送設(shè)置命令比如設(shè)置Quad模式、設(shè)置延遲、設(shè)置驅(qū)動強度、讀取設(shè)備ID確認芯片在線、然后才能正常讀寫。很多人在上電后立刻讀寫PSRAM結(jié)果讀回的ID是錯的或者讀到的數(shù)據(jù)偶發(fā)錯誤就是因為上電穩(wěn)定時間不夠芯片內(nèi)部狀態(tài)還沒準備好。讀寫時序上最容易被忽略的是寫使能機制。PSRAM和Flash一樣寫操作前通常需要發(fā)送Write Enable0x06命令然后才能執(zhí)行Page Program等寫命令。如果你在代碼里漏了這一步或者中斷在寫使能之后、寫命令之前插入導(dǎo)致時序被拉長某些芯片會判定操作非法數(shù)據(jù)就沒寫進去。實測中這類問題在SPI時鐘開得越高時越明顯因為時序裕量變小了。還有一個坑是刷新與DMA的配合。SPI PSRAM內(nèi)部刷新時會暫緩來自外部總線的訪問這在單次CPU讀寫上感覺不到但如果你用DMA做大批量傳輸而且DMA的超時設(shè)置比較緊就可能偶發(fā)超時。別問我怎么踩到的——調(diào)試一塊PSRAM上的攝像頭圖像緩沖區(qū)時圖像正常了99%但每隔幾秒就閃一幀花屏最后查到DMA配置里把PSRAM讀寫超時設(shè)成了實時性要求更高的數(shù)值放寬后問題消失。2.3 實測幾個典型的PSRAM翻車場景場景一低溫下初始化失敗。有一批板子在常溫實驗室一切正常放到-20℃環(huán)境做老化測試大概有3%的板子啟動后內(nèi)存檢測失敗。排查發(fā)現(xiàn)是PSRAM上電穩(wěn)定時間在低溫下變長了固件里固定的延時不夠。把初始化前的等待從500μs加到了2ms并增加了讀取ID后校驗的邏輯失敗率歸零。這里要注意datasheet給的是典型值工程上要做覆蓋全溫區(qū)的裕量設(shè)計。場景二Quad模式讀出來是亂的。當(dāng)時為了提升刷新率把PSRAM切到Quad I/O模式結(jié)果屏幕開始出馬賽克。檢查發(fā)現(xiàn)是切換模式后后續(xù)所有訪問命令都要帶上模式位Mode Bit但代碼里只有部分路徑寫了模式位另一條DMA訪問路徑?jīng)]帶導(dǎo)致芯片一直在不同模式間橫跳。這類問題最好的排查方法就是抓SPI波形逐個命令比對不要猜。場景三PSRAM和外部Flash共享SPI總線的沖突。某些低成本方案會讓PSRAM和SPI NOR Flash掛在同一個SPI控制器上用片選分開。如果片選切換之間沒有留足夠的時間一般要求CS拉高再拉低之間至少有個小延時兩條總線上的設(shè)備可能被對方的殘余信號干擾。我一般至少留250ns~500ns。實測某些芯片對CS釋放后的保持時間非常敏感少了它偶爾就會出現(xiàn)Flash寫入失敗或PSRAM數(shù)據(jù)錯亂。3. NOR Flash的慢性子擦寫壽命與掉電的不確定性3.1 NOR和NAND別再傻傻分不清討論NOR Flash之前先回應(yīng)很多新手朋友問過的問題NAND Flash和NOR Flash到底有什么區(qū)別簡單版回答NOR可以按字節(jié)/字隨機讀取讀得快、可靠性高適合直接XIP執(zhí)行代碼但寫和擦除很慢容量做大之后成本高NAND按頁讀寫寫入擦除快、容量大、成本低但隨機讀取延遲高、壞塊多、需要文件系統(tǒng)層做壞塊管理和ECC不適合直接執(zhí)行代碼。所以產(chǎn)品里通常拿NOR放Bootloader和固件拿NAND或eMMC放文件系統(tǒng)和大塊數(shù)據(jù)。但要說清不確定性必須補充一個深層區(qū)別NOR Flash的存儲單元是浮柵晶體管擦除操作靠Fowler-Nordheim隧穿把電子從浮柵里拉出來編程操作則往浮柵里注入電子。隧穿和注入都是概率性物理過程所以擦除和編程時間天然有浮動。datasheet里會給出典型值和最大值比如Sector Erase典型值45ms最大值400ms這個最大不是隨隨便便寫的你不等夠狀態(tài)機就可能沒走完。3.2 上電、擦寫、復(fù)位里那些說不準的環(huán)節(jié)NOR Flash在上電時有一段Power-On Reset時間期間器件對命令不響應(yīng)。如果你在上電后立即發(fā)JEDEC ID讀取命令0x9F很多芯片會返回垃圾數(shù)據(jù)或者直接不拉低MISO。我見過一堆代碼在Bootloader里讀Flash ID來校驗硬件版本結(jié)果因為延時不夠讀回0xFFFFFFFF就誤報硬件錯誤。解決方法是上電后至少延時幾十毫秒再訪問Flash并且對ID做多重校驗。擦寫流程里最容易被坑的是狀態(tài)寄存器的寫保護位。SPI NOR Flash為了保證可靠性默認會對狀態(tài)寄存器做非易失寫保護Status Register ProtectSRP位。很多人拿到新片直接發(fā)擦除命令結(jié)果怎么擦都擦不動因為WP#引腳被拉高時寫保護生效。不同的芯片默認保護級別也不同比如W25Q系列默認BP位為0、不保護主存儲區(qū)但某些國產(chǎn)芯片出廠BP位是設(shè)置好的所以兼容性測試一定要做讀取狀態(tài)寄存器這步。這個我在后面速查表里還會提。還有一個經(jīng)常被忽略的點4字節(jié)地址模式。容量超過16MB的Flash默認上電大多在3字節(jié)地址模式訪問高16MB地址時必須發(fā)命令切換到4字節(jié)地址模式B7h有些芯片是帶Entry/Exit的。切換命令本身是非易失的還是易失的芯片間也有差異。如果你用的是類似MX25L25645G這樣的芯片一定要查清楚上電后的默認地址模式否則燒錄地址超過16MB時數(shù)據(jù)會寫到錯誤的位置。3.3 量產(chǎn)燒錄與掉電保護的實操要點量產(chǎn)場景下NOR Flash不確定性最典型的表現(xiàn)是燒錄中途掉電固件變成磚。對此我的做法是固件里設(shè)計A/B雙分區(qū)加啟動標志位新固件先寫到B區(qū)全部寫完并校驗通過后再更新啟動標志指向B區(qū)如果中途掉電Bootloader檢測到標志無效自動回退到A區(qū)。這套流程看起來多占一倍的Flash空間但換來的是現(xiàn)場幾乎不再出現(xiàn)救磚任務(wù)。對于沒有雙分區(qū)空間的低成本產(chǎn)品至少要保證先擦后寫過程中意外掉電后Bootloader能檢測到固件區(qū)校驗失敗并進入DFU等待狀態(tài)而不是直接跳到空代碼區(qū)執(zhí)行。此外擦除/編程的超時處理一定要用輪詢WIP位 最大超時兜底的方式。WIPWrite In Progress位在狀態(tài)寄存器1的最低位bit 0每次發(fā)0x05命令讀狀態(tài)寄存器bit 0為1表示忙輪詢到0表示操作完成。很多工程師只做一次性等待固定延時這在溫度漂移和芯片批次差異面前早晚會翻車。輪詢邏輯本身很簡單但要注意輪詢間隔一般建議100μs左右防抖次數(shù)按datasheet最大值的1.5~2倍來設(shè)這樣既不會過早超時報錯也不會卡死系統(tǒng)。4. USB的社交枚舉、驅(qū)動與協(xié)議的不確定性4.1 枚舉一次連接本質(zhì)上是一場握手談判要理解USB的不確定性先要理解它的本質(zhì)USB是一種主機主動、設(shè)備被動響應(yīng)的協(xié)議。設(shè)備插入后主機通過D/D-電平變化檢測到設(shè)備連接然后對設(shè)備地址0發(fā)起一系列控制傳輸Get Device Descriptor、Set Address、Get Configuration Descriptor等這個過程叫枚舉。枚舉的成功與否取決于設(shè)備能否在150ms左右的時間窗口內(nèi)按照主機期望的節(jié)奏響應(yīng)每一個請求。不確定性就藏在這個過程里。任何一個環(huán)節(jié)慢了、錯了、超時了主機就會認為設(shè)備異常要么報告無法識別的USB設(shè)備要么設(shè)備在設(shè)備管理器里反復(fù)嘆號。更要命的是不同主機控制器Intel、AMD、ASMedia、瑞薩對時序的嚴格程度不一樣同一臺設(shè)備在A電腦上插入即用在B電腦上就是不穩(wěn)定。這也是USB調(diào)試最磨人的地方——你沒法保證用戶手上的電腦形態(tài)。4.2 設(shè)備端常見枚舉失敗硬件、描述符、時鐘設(shè)備端導(dǎo)致枚舉失敗的原因按我踩坑的頻率排序D/D-上拉電阻不對全速設(shè)備Full Speed 12Mbps需要在D上拉1.5kΩ到3.3V低速設(shè)備在D-上拉。如果用MCU內(nèi)部上拉阻值偏差會導(dǎo)致主機檢測不到連接。很多MCU比如STM32系列內(nèi)部集成了這個上拉但需要軟件在檢測到VBUS后再使能順序錯了設(shè)備就不出現(xiàn)在總線上。時鐘精度不夠USB全速要求源時鐘誤差在±0.25%以內(nèi)高速更是要到±0.05%。這個精度直接決定位時間對不對很多低成本MCU用內(nèi)部RC振蕩器跑USB會偶發(fā)枚舉失敗換外部晶振后就好了。我遇到過一批板子用內(nèi)部HSI跑STM32F407的USB虛擬串口90%能枚舉成功10%需要拔插兩次才行最后全部改成外部25MHz晶振問題消失。描述符錯誤描述符里任何一個長度、端點地址、接口數(shù)量不匹配主機都可能拒絕設(shè)備。尤其是CDC虛擬串口需要類特殊描述符Union Functional Descriptor、Call Management Functional Descriptor等少一個或者順序不對Windows會直接報告該設(shè)備無法啟動Code 10。排查這類問題最有效的是用USB協(xié)議分析儀或抓包軟件下面細說。供電不足設(shè)備從USB口取電如果板載外圍太多、瞬間電流超過500mAUSB 2.0標準主機端口會過流保護。這個屬于電氣不確定性但復(fù)現(xiàn)率不低、誤判率也高排查時先量一下設(shè)備實際功耗。4.3 主機端驅(qū)動與工具從FT232R到Wireshark主機端最常見的不確定性來自驅(qū)動。USB轉(zhuǎn)串口芯片F(xiàn)T232R、FT231X、CP2102N、CH340這些本身很成熟但驅(qū)動安裝不上、版本沖突、簽名問題能讓人折騰半天。我自己處理這類問題的小技巧優(yōu)先用官方驅(qū)動不要用第三方萬能驅(qū)動。FTDI的驅(qū)動對FT232R/FT231X支持很完善Silicon Labs的CP2102N驅(qū)動也比較干凈。裝了驅(qū)動后在設(shè)備管理器里看端口號是否出現(xiàn)、驅(qū)動版本是否匹配。如果設(shè)備在設(shè)備管理器里顯示未知設(shè)備先用USB Device Tree Viewer去看設(shè)備到底有沒有成功枚舉——它能顯示設(shè)備處于什么狀態(tài)、拿到了什么地址、配置描述符解析是否正常。如果是枚舉成功了但驅(qū)動沒加載那是驅(qū)動問題如果連配置都沒有那是設(shè)備端問題。抓包分析用Wireshark加USBPcap。很多人以為Wireshark只能抓網(wǎng)絡(luò)包其實它配合USBPcap可以抓USB總線上的URBUSB Request Block能看到主機發(fā)了什么請求、設(shè)備回了什么數(shù)據(jù)。排查枚舉失敗時非常有用。我舉一個真實的排查案例一塊板子的USB虛擬串口在Windows 10上穩(wěn)定但升級到Windows 11后偶發(fā)斷連。用Wireshark抓包發(fā)現(xiàn)新系統(tǒng)會周期性發(fā)送Get Status請求設(shè)備端響應(yīng)偶爾超過150ms超時于是主機把設(shè)備斷開重枚舉。最后定位是USB中斷服務(wù)函數(shù)里有一個耗時很長的Flash擦除操作擦除期間USB中斷被屏蔽了請求得不到及時響應(yīng)。把Flash擦除拆成多段、每段之間開中斷問題解決。這個案例正好能說明USB的不確定性很多時候不是USB本身的問題而是系統(tǒng)里其他設(shè)備的時序問題傳染給了USB。4.4 Host、Device、OTG三模式的區(qū)別與選擇關(guān)于USB Host模式、Device模式和OTG很多新手容易混淆。直接說結(jié)論Host模式負責(zé)供電、管理枚舉類似電腦那端接口用A型口Device模式是被動響應(yīng)類似U盤、手機那端接口用B型口或Micro-BOTG則在一條線纜上通過ID引腳識別自己是Host還是Device適合手機、平板這種需要角色動態(tài)切換的設(shè)備。嵌入式產(chǎn)品選型時如果只是給PC當(dāng)外設(shè)用Device模式即可STM32F407這類MCU的USB模塊做虛擬串口非常方便。如果需要直接插U盤、鍵鼠就得用Host模式這時候要考慮VBUS供電能力、根集線器開銷和驅(qū)動棧復(fù)雜度會上升一個量級。OTG模式適合既想連PC又想插U盤的產(chǎn)品但要注意ID引腳的檢測邏輯以及角色切換時總線的重新枚舉處理不好會出現(xiàn)插上電腦沒反應(yīng)、反插又不能用的怪問題。量產(chǎn)時我通常建議固定角色的產(chǎn)品不要用OTG直接按Host或Device設(shè)計能省掉一半的疑難雜癥。5. 三個子系統(tǒng)聯(lián)動時的不確定性傳染5.1 USB OTG燒寫Flash量產(chǎn)場景下的鏈路梳理搜索熱詞里有一條USB OTG燒寫NAND Flash這確實是量產(chǎn)和售后經(jīng)常會用到的形式主機通過USB把固件發(fā)給設(shè)備設(shè)備里的Bootloader再把固件寫入NOR/NAND Flash。這里面每一環(huán)都帶著前面幾章講到的不確定性很容易做個所謂燒錄成功率99%的上位機結(jié)果現(xiàn)場就是不停有人燒錄失敗。我建議把整條鏈路梳理成可觀測的環(huán)節(jié)再設(shè)計容錯USB枚舉是否成功、設(shè)備是否收到完整固件包CRC校驗、Flash擦寫是否完成WIP輪詢、寫入后回讀校驗是否通過。任何一個環(huán)節(jié)失敗都要有明確反饋和重試機制。我還習(xí)慣在燒錄協(xié)議里加入分塊序號CRC設(shè)計單塊失敗則重傳單塊而不是整包重傳Flash擦除采用按扇區(qū)擦除而不是整片擦除這樣即使掉電已傳完的分區(qū)還能保留支持斷點續(xù)傳。這套方案在代工廠和售后現(xiàn)場用下來燒錄失敗率從千分之一級別降到了幾乎不可見。5.2 共享SPI總線與電源域時的彼此干擾很多中型MCU只有1~2個SPI外設(shè)PSRAM和NOR Flash共用同一SPI總線、用不同CS片選的情況非常常見。這種方案省引腳但換來的是時序耦合。最大的坑是兩個設(shè)備對片選釋放后的保持時間要求不同PSRAM往往要求CS拉高后至少幾十納秒才能再次拉低而某些NOR Flash要求更長。如果你在寫完P(guān)SRAM后立刻切到Flash操作系統(tǒng)里又有其他中斷插入CS之間的間隔就可能不夠?qū)е翭lash識別到異常的SPI通信偶發(fā)地錯誤寫入或狀態(tài)寄存器被改。另外PSRAM是DRAM核心刷新期間對供電紋波比較敏感NOR Flash擦除時電流會突然沖高如果兩個器件共用一個LDO擦除瞬間的電流尖峰會把PSRAM的供電電壓拉低輕則刷新失敗丟數(shù)據(jù)重則系統(tǒng)復(fù)位。我通常會給它們分別配LDO或至少加大Bulk電容并在PCB布局上讓PSRAM的退耦電容盡量靠近電源引腳。5.3 一次USB枚舉把系統(tǒng)搞崩的排查實錄最后分享一個印象很深的聯(lián)調(diào)事故。設(shè)備上電后如果先讓PSRAM完成初始化再開USB一切正常但如果USB先被主機檢測到、枚舉中斷先來了而PSRAM還沒初始化完系統(tǒng)就會在USB中斷服務(wù)里訪問未初始化的PSRAM觸發(fā)總線錯誤直接HardFault。排查時一開始完全沒頭緒現(xiàn)象是偶發(fā)死機且發(fā)生在插拔USB時。后來在HardFault中斷里打印出出錯地址發(fā)現(xiàn)出錯地址落在PSRAM映射區(qū)域內(nèi)才把矛頭指向初始化順序。修復(fù)方案有兩種要么在PSRAM初始化完成前不使能USB中斷要么在USB中斷處理里加一個PSRAM就緒標志的保護。我最后選了第二種因為對系統(tǒng)啟動時間更友好。同時還加了一個調(diào)試開關(guān)可以在初始化階段通過串口打印每個外設(shè)的就緒狀態(tài)避免再次出現(xiàn)這種無聲無息的初始化順序問題。這個案例很能說明三個子系統(tǒng)單獨看都沒問題湊在一起就會出現(xiàn)不確定性傳染。排障的時候不要只盯著USB協(xié)議棧也要看它調(diào)用的資源內(nèi)存、Flash、時鐘是不是還沒準備好。6. 排查方法論與避坑速查表6.1 把玄學(xué)變成科學(xué)的四個步驟這類多外設(shè)聯(lián)動的不確定性問題最忌憑感覺改代碼。我總結(jié)了一套流程按順序執(zhí)行大部分問題都能收斂。第一步固定現(xiàn)場。復(fù)現(xiàn)異常時記錄供電電壓、環(huán)境溫度、固件版本、操作序列最好能截圖或錄屏。不能復(fù)現(xiàn)的問題先不要動代碼先想清楚當(dāng)時的輸入條件。第二步分層隔離。把系統(tǒng)切成獨立模塊逐層驗證。USB枚舉失敗先查設(shè)備端能否單獨枚舉成功再查驅(qū)動再查協(xié)議Flash擦寫異常先單獨驗證Flash讀寫再驗證文件系統(tǒng)層不要一上來就懷疑某一層。第三步加觀測點。在代碼里加日志、狀態(tài)寄存器快照、錯誤計數(shù)。很多偶發(fā)問題其實是狀態(tài)被覆蓋了加上觀測點后能看到真正出錯的位置。觀測點要盡量輕量不要改變原有時序否則可能測不出來。第四步做對照實驗。改一個變量跑一批測試統(tǒng)計成功率。改兩個以上變量結(jié)果就很難歸因了。比如懷疑是PSRAM刷新問題還是USB驅(qū)動問題就分別做只跑PSRAM壓測和只跑USB枚舉測試對比數(shù)據(jù)。6.2 問題速查表癥狀、原因、排查手段下面這個表是我在項目群里經(jīng)常貼出來的基本覆蓋了這三個子系統(tǒng)的常見問題癥狀可能的不確定性來源建議排查手段上電后Flash ID讀錯或全F上電復(fù)位時間不夠、供電不穩(wěn)加大上電延時讀ID前先發(fā)復(fù)位指令校驗IDFlash擦除不成功寫不進去狀態(tài)寄存器寫保護SRP/BP位、WP#引腳被拉高讀狀態(tài)寄存器按需發(fā)解鎖命令檢查WP#硬件Flash擦寫偶發(fā)失敗系統(tǒng)死機擦寫時間超過預(yù)置延時、共享SPI總線沖突改成WIP輪詢最大超時兜底檢查CS切換間隔16MB以上Flash地址錯亂3字節(jié)/4字節(jié)地址模式切換遺漏確認芯片上電默認模式按芯片手冊發(fā)模式切換命令PSRAM初始化失敗/數(shù)據(jù)錯誤上電穩(wěn)定時間不足、Latency配置錯、模式位漏設(shè)增大穩(wěn)定延時讀ID校驗抓SPI波形比對命令序列PSRAM偶發(fā)花屏/數(shù)據(jù)錯亂DMA超時設(shè)置較短、共享總線干擾、電源紋波放寬DMA超時CS間隔加長檢查供電退耦USB枚舉偶爾失敗時鐘精度不足、D上拉時序不對、線纜過長換外部晶振檢查上拉使能時機換短線測試USB在Windows上嘆號描述符錯誤、驅(qū)動異常、供電不足用USB Device Tree Viewer查狀態(tài)抓Wireshark包量電流USB虛擬串口偶發(fā)斷連USB中斷響應(yīng)超時、系統(tǒng)其他任務(wù)占用時間過長檢查中斷服務(wù)耗時拆分長任務(wù)調(diào)整中斷優(yōu)先級USB OTG燒錄Flash失敗鏈路中未做CRC/分塊斷點、Flash擦寫沒確認上位機和固件都加CRC分塊重傳機制輪詢WIP確認6.3 我這些年用下來最順手的工具與習(xí)慣工具方面硬件上我建議備常用的邏輯分析儀至少16通道、100MHz以上、USB協(xié)議分析儀預(yù)算不足可以先用WiresharkUSBPcap替代、支持模擬/數(shù)字雙通道的示波器。軟件上USB Device Tree Viewer、Wireshark、總線抓取工具、串口調(diào)試助手這幾個常備。Flash和PSRAM排障時邏輯分析儀抓SPI波形基本一抓一個準比盲改代碼高效太多。習(xí)慣上我有幾個一直堅持的做法。第一所有外設(shè)初始化代碼都做成可配置、可打印狀態(tài)的調(diào)試接口跑起來后先看狀態(tài)再看現(xiàn)象。第二關(guān)鍵行為Flash擦寫、USB枚舉、PSRAM初始化都加超時監(jiān)控和錯誤上報寧可多打印幾行日志也不要讓錯誤被吞掉。第三凡是涉及延時的地方全部都寫成宏或配置文件方便做全溫區(qū)、全電壓測試時批量調(diào)整。最后也是最重要的遇到玄學(xué)問題先忍住不亂改按上面四步走絕大多數(shù)問題都能在一個小時內(nèi)定位到物理層面或協(xié)議層面的真實原因。我個人這幾年的體會是PSRAM、NOR Flash、USB這類標準外設(shè)之所以還讓人頭疼不是因為它們本身有多復(fù)雜而是因為它們各自的不確定性疊加在一起時會呈現(xiàn)出系統(tǒng)級的詭異現(xiàn)象。把每個子系統(tǒng)的物理原理、時序邊界吃透再配合結(jié)構(gòu)化的排查方法那些看似隨機的問題其實都能收斂成確定的Bug。最后再分享一個小技巧在所有涉及等待外設(shè)就緒的代碼里我都會留一個帶時間戳的日志把每個階段的等待時間打印出來。這樣在復(fù)現(xiàn)故障時只要看一眼日志就能知道到底是哪個環(huán)節(jié)的時間裕量不夠比抓瞎式排查快得多。希望這篇內(nèi)容能幫你在下個項目里少踩幾個坑。 嵌入式外設(shè)不確定性排查：PSRAM、NOR Flash與USB實戰(zhàn)經(jīng)驗
做嵌入式這幾年P(guān)SRAM、NOR Flash、USB這三個名字我?guī)缀跆焯齑蚪坏馈Ｒ粋€是內(nèi)存擴展一個是代碼與參數(shù)的存放地一個是和外部世界通信的接口——聽起來都是再標準不過的外設(shè)?？烧嬲阉鼈兘M合在一個系統(tǒng)里跑穩(wěn)定尤其是要在量產(chǎn)線上批量復(fù)現(xiàn)時你會發(fā)現(xiàn)不確定性這三個字幾乎無處不在。同一顆芯片、同一份代碼有的板子一次過有的板子偶發(fā)枚舉失敗有的設(shè)備低溫下代碼加載直接卡死。這不是玄學(xué)而是這三類器件在物理層和協(xié)議層本身就帶著一批說不準的行為工程上如果不去理解這些不確定性就會在排障時走很多彎路。這篇文章把我這些年調(diào)PSRAM、NOR Flash、USB時踩過的坑、驗證過的方法和最終沉淀下來的排查套路一次性整理出來適合正在做MCU/嵌入式Linux產(chǎn)品方案的工程師也適合剛?cè)胧諷TM32、ESP32等平臺、被外設(shè)穩(wěn)定性問題折磨的新手。內(nèi)容不追求面面俱到重點是把為什么會出現(xiàn)不確定性和怎么把它管住講透看完你至少能少熬夜調(diào)幾個Bug。1. 一個翻車現(xiàn)場引出的三個不確定性1.1 項目背景PSRAM、NOR Flash、USB為什么會湊到一起先還原一下我經(jīng)歷過的一個典型場景。某款帶屏的IoT產(chǎn)品主控選了帶PSRAM擴展的MCU方案PSRAM用來跑UI緩沖和音頻緩沖固件放在一顆8MB的NOR Flash里上電后由Bootloader從Flash搬運到內(nèi)部SRAM/PSRAM執(zhí)行同時設(shè)備通過USB Device接口連接電腦既要做USB虛擬串口CDC做日志輸出還要支持DFU固件升級。這個組合在今天其實非常常見。PSRAM解決內(nèi)存不夠用NOR Flash解決代碼和參數(shù)怎么可靠存放USB解決怎么跟PC交互。三者看似各管一攤但在實際調(diào)試中它們會互相作用USB枚舉瞬間的電流波動能干擾PSRAM的供電NOR Flash擦除時被USB的中斷打斷可能導(dǎo)致擦除流程異常PSRAM初始化沒完成時USB描述符中斷來了系統(tǒng)直接死機。要理清這些就得先把每一類器件的不確定性單獨拿出來看。1.2 所謂不確定性到底指的是什么我理解的不確定性不是量子力學(xué)那種真隨機而是指器件的某個行為在datasheet的典型條件下是確定的但在真實系統(tǒng)里因為供電、溫度、時序、代碼順序、總線復(fù)用等原因結(jié)果變得難以預(yù)測。具體分四類時序不確定性上電穩(wěn)定時間、指令間隔、擦寫完成時間都有最小/最大范圍超時和欠時都可能出錯。電氣不確定性信號沿的抖動、電源紋波、PCB寄生參數(shù)、線纜阻抗等會讓數(shù)據(jù)采樣點在臨界區(qū)浮動。協(xié)議狀態(tài)不確定性USB枚舉、Flash狀態(tài)機、PSRAM刷新等都有內(nèi)部狀態(tài)外部事件如中斷、掉電切入時狀態(tài)機會落在不可預(yù)期的位置。上下文不確定性同樣的代碼在不同主頻、不同編譯器優(yōu)化等級、不同GPIO初始化順序下行為不同。這類最坑因為復(fù)現(xiàn)困難。這四類不確定性的背后是物理和協(xié)議的復(fù)雜機制。后面三章我會逐個拆解并且給出實操層面的管住它們的辦法。2. PSRAM的藏著掖著刷新與時序的不確定性2.1 先說原理PSRAM為什么叫偽SRAMPSRAMPseudo SRAM偽靜態(tài)隨機存儲器的存儲核心其實是DRAM只是外部接口做成了SRAM的樣子。你不需要像用SDRAM那樣去管理行激活、預(yù)充電、刷新這些細節(jié)直接像SRAM一樣讀寫就行。代價是芯片內(nèi)部有一個隱藏的刷新邏輯它會周期性對存儲單元做刷新。這個刷新過程對使用者來說是不可見的但它會對總線的可用帶寬產(chǎn)生影響。某些時候你讀一個地址正好碰上內(nèi)部刷新周期返回數(shù)據(jù)的延遲就會比平時大一點。這就是PSRAM第一個不確定性的來源——訪問延遲不是恒定值。另一個層面SPI接口的PSRAM比如APS6404、LY68L6400、IPS6404在MCU項目里用得越來越多。它的好處是引腳少、布線簡單但代價是協(xié)議里引入了等待周期Latency的概念。讀操作發(fā)出命令后數(shù)據(jù)并不會立刻出現(xiàn)在MOSI上而是要等若干個dummy cycle。這個dummy cycle的數(shù)量又跟工作頻率、指令模式、芯片配置有關(guān)。配置錯了要么讀到全0要么數(shù)據(jù)錯位而且不同廠家的芯片行為還不完全一樣非常容易出問題。2.2 初始化與讀寫時最容易踩的時序坑SPI PSRAM的初始化一般分幾步上電等待VCC穩(wěn)定至少幾百微秒到1ms具體看型號、發(fā)送復(fù)位命令、發(fā)送設(shè)置命令比如設(shè)置Quad模式、設(shè)置延遲、設(shè)置驅(qū)動強度、讀取設(shè)備ID確認芯片在線、然后才能正常讀寫。很多人在上電后立刻讀寫PSRAM結(jié)果讀回的ID是錯的或者讀到的數(shù)據(jù)偶發(fā)錯誤就是因為上電穩(wěn)定時間不夠芯片內(nèi)部狀態(tài)還沒準備好。讀寫時序上最容易被忽略的是寫使能機制。PSRAM和Flash一樣寫操作前通常需要發(fā)送Write Enable0x06命令然后才能執(zhí)行Page Program等寫命令。如果你在代碼里漏了這一步或者中斷在寫使能之后、寫命令之前插入導(dǎo)致時序被拉長某些芯片會判定操作非法數(shù)據(jù)就沒寫進去。實測中這類問題在SPI時鐘開得越高時越明顯因為時序裕量變小了。還有一個坑是刷新與DMA的配合。SPI PSRAM內(nèi)部刷新時會暫緩來自外部總線的訪問這在單次CPU讀寫上感覺不到但如果你用DMA做大批量傳輸而且DMA的超時設(shè)置比較緊就可能偶發(fā)超時。別問我怎么踩到的——調(diào)試一塊PSRAM上的攝像頭圖像緩沖區(qū)時圖像正常了99%但每隔幾秒就閃一幀花屏最后查到DMA配置里把PSRAM讀寫超時設(shè)成了實時性要求更高的數(shù)值放寬后問題消失。2.3 實測幾個典型的PSRAM翻車場景場景一低溫下初始化失敗。有一批板子在常溫實驗室一切正常放到-20℃環(huán)境做老化測試大概有3%的板子啟動后內(nèi)存檢測失敗。排查發(fā)現(xiàn)是PSRAM上電穩(wěn)定時間在低溫下變長了固件里固定的延時不夠。把初始化前的等待從500μs加到了2ms并增加了讀取ID后校驗的邏輯失敗率歸零。這里要注意datasheet給的是典型值工程上要做覆蓋全溫區(qū)的裕量設(shè)計。場景二Quad模式讀出來是亂的。當(dāng)時為了提升刷新率把PSRAM切到Quad I/O模式結(jié)果屏幕開始出馬賽克。檢查發(fā)現(xiàn)是切換模式后后續(xù)所有訪問命令都要帶上模式位Mode Bit但代碼里只有部分路徑寫了模式位另一條DMA訪問路徑?jīng)]帶導(dǎo)致芯片一直在不同模式間橫跳。這類問題最好的排查方法就是抓SPI波形逐個命令比對不要猜。場景三PSRAM和外部Flash共享SPI總線的沖突。某些低成本方案會讓PSRAM和SPI NOR Flash掛在同一個SPI控制器上用片選分開。如果片選切換之間沒有留足夠的時間一般要求CS拉高再拉低之間至少有個小延時兩條總線上的設(shè)備可能被對方的殘余信號干擾。我一般至少留250ns~500ns。實測某些芯片對CS釋放后的保持時間非常敏感少了它偶爾就會出現(xiàn)Flash寫入失敗或PSRAM數(shù)據(jù)錯亂。3. NOR Flash的慢性子擦寫壽命與掉電的不確定性3.1 NOR和NAND別再傻傻分不清討論NOR Flash之前先回應(yīng)很多新手朋友問過的問題NAND Flash和NOR Flash到底有什么區(qū)別簡單版回答NOR可以按字節(jié)/字隨機讀取讀得快、可靠性高適合直接XIP執(zhí)行代碼但寫和擦除很慢容量做大之后成本高NAND按頁讀寫寫入擦除快、容量大、成本低但隨機讀取延遲高、壞塊多、需要文件系統(tǒng)層做壞塊管理和ECC不適合直接執(zhí)行代碼。所以產(chǎn)品里通常拿NOR放Bootloader和固件拿NAND或eMMC放文件系統(tǒng)和大塊數(shù)據(jù)。但要說清不確定性必須補充一個深層區(qū)別NOR Flash的存儲單元是浮柵晶體管擦除操作靠Fowler-Nordheim隧穿把電子從浮柵里拉出來編程操作則往浮柵里注入電子。隧穿和注入都是概率性物理過程所以擦除和編程時間天然有浮動。datasheet里會給出典型值和最大值比如Sector Erase典型值45ms最大值400ms這個最大不是隨隨便便寫的你不等夠狀態(tài)機就可能沒走完。3.2 上電、擦寫、復(fù)位里那些說不準的環(huán)節(jié)NOR Flash在上電時有一段Power-On Reset時間期間器件對命令不響應(yīng)。如果你在上電后立即發(fā)JEDEC ID讀取命令0x9F很多芯片會返回垃圾數(shù)據(jù)或者直接不拉低MISO。我見過一堆代碼在Bootloader里讀Flash ID來校驗硬件版本結(jié)果因為延時不夠讀回0xFFFFFFFF就誤報硬件錯誤。解決方法是上電后至少延時幾十毫秒再訪問Flash并且對ID做多重校驗。擦寫流程里最容易被坑的是狀態(tài)寄存器的寫保護位。SPI NOR Flash為了保證可靠性默認會對狀態(tài)寄存器做非易失寫保護Status Register ProtectSRP位。很多人拿到新片直接發(fā)擦除命令結(jié)果怎么擦都擦不動因為WP#引腳被拉高時寫保護生效。不同的芯片默認保護級別也不同比如W25Q系列默認BP位為0、不保護主存儲區(qū)但某些國產(chǎn)芯片出廠BP位是設(shè)置好的所以兼容性測試一定要做讀取狀態(tài)寄存器這步。這個我在后面速查表里還會提。還有一個經(jīng)常被忽略的點4字節(jié)地址模式。容量超過16MB的Flash默認上電大多在3字節(jié)地址模式訪問高16MB地址時必須發(fā)命令切換到4字節(jié)地址模式B7h有些芯片是帶Entry/Exit的。切換命令本身是非易失的還是易失的芯片間也有差異。如果你用的是類似MX25L25645G這樣的芯片一定要查清楚上電后的默認地址模式否則燒錄地址超過16MB時數(shù)據(jù)會寫到錯誤的位置。3.3 量產(chǎn)燒錄與掉電保護的實操要點量產(chǎn)場景下NOR Flash不確定性最典型的表現(xiàn)是燒錄中途掉電固件變成磚。對此我的做法是固件里設(shè)計A/B雙分區(qū)加啟動標志位新固件先寫到B區(qū)全部寫完并校驗通過后再更新啟動標志指向B區(qū)如果中途掉電Bootloader檢測到標志無效自動回退到A區(qū)。這套流程看起來多占一倍的Flash空間但換來的是現(xiàn)場幾乎不再出現(xiàn)救磚任務(wù)。對于沒有雙分區(qū)空間的低成本產(chǎn)品至少要保證先擦后寫過程中意外掉電后Bootloader能檢測到固件區(qū)校驗失敗并進入DFU等待狀態(tài)而不是直接跳到空代碼區(qū)執(zhí)行。此外擦除/編程的超時處理一定要用輪詢WIP位 最大超時兜底的方式。WIPWrite In Progress位在狀態(tài)寄存器1的最低位bit 0每次發(fā)0x05命令讀狀態(tài)寄存器bit 0為1表示忙輪詢到0表示操作完成。很多工程師只做一次性等待固定延時這在溫度漂移和芯片批次差異面前早晚會翻車。輪詢邏輯本身很簡單但要注意輪詢間隔一般建議100μs左右防抖次數(shù)按datasheet最大值的1.5~2倍來設(shè)這樣既不會過早超時報錯也不會卡死系統(tǒng)。4. USB的社交枚舉、驅(qū)動與協(xié)議的不確定性4.1 枚舉一次連接本質(zhì)上是一場握手談判要理解USB的不確定性先要理解它的本質(zhì)USB是一種主機主動、設(shè)備被動響應(yīng)的協(xié)議。設(shè)備插入后主機通過D/D-電平變化檢測到設(shè)備連接然后對設(shè)備地址0發(fā)起一系列控制傳輸Get Device Descriptor、Set Address、Get Configuration Descriptor等這個過程叫枚舉。枚舉的成功與否取決于設(shè)備能否在150ms左右的時間窗口內(nèi)按照主機期望的節(jié)奏響應(yīng)每一個請求。不確定性就藏在這個過程里。任何一個環(huán)節(jié)慢了、錯了、超時了主機就會認為設(shè)備異常要么報告無法識別的USB設(shè)備要么設(shè)備在設(shè)備管理器里反復(fù)嘆號。更要命的是不同主機控制器Intel、AMD、ASMedia、瑞薩對時序的嚴格程度不一樣同一臺設(shè)備在A電腦上插入即用在B電腦上就是不穩(wěn)定。這也是USB調(diào)試最磨人的地方——你沒法保證用戶手上的電腦形態(tài)。4.2 設(shè)備端常見枚舉失敗硬件、描述符、時鐘設(shè)備端導(dǎo)致枚舉失敗的原因按我踩坑的頻率排序D/D-上拉電阻不對全速設(shè)備Full Speed 12Mbps需要在D上拉1.5kΩ到3.3V低速設(shè)備在D-上拉。如果用MCU內(nèi)部上拉阻值偏差會導(dǎo)致主機檢測不到連接。很多MCU比如STM32系列內(nèi)部集成了這個上拉但需要軟件在檢測到VBUS后再使能順序錯了設(shè)備就不出現(xiàn)在總線上。時鐘精度不夠USB全速要求源時鐘誤差在±0.25%以內(nèi)高速更是要到±0.05%。這個精度直接決定位時間對不對很多低成本MCU用內(nèi)部RC振蕩器跑USB會偶發(fā)枚舉失敗換外部晶振后就好了。我遇到過一批板子用內(nèi)部HSI跑STM32F407的USB虛擬串口90%能枚舉成功10%需要拔插兩次才行最后全部改成外部25MHz晶振問題消失。描述符錯誤描述符里任何一個長度、端點地址、接口數(shù)量不匹配主機都可能拒絕設(shè)備。尤其是CDC虛擬串口需要類特殊描述符Union Functional Descriptor、Call Management Functional Descriptor等少一個或者順序不對Windows會直接報告該設(shè)備無法啟動Code 10。排查這類問題最有效的是用USB協(xié)議分析儀或抓包軟件下面細說。供電不足設(shè)備從USB口取電如果板載外圍太多、瞬間電流超過500mAUSB 2.0標準主機端口會過流保護。這個屬于電氣不確定性但復(fù)現(xiàn)率不低、誤判率也高排查時先量一下設(shè)備實際功耗。4.3 主機端驅(qū)動與工具從FT232R到Wireshark主機端最常見的不確定性來自驅(qū)動。USB轉(zhuǎn)串口芯片F(xiàn)T232R、FT231X、CP2102N、CH340這些本身很成熟但驅(qū)動安裝不上、版本沖突、簽名問題能讓人折騰半天。我自己處理這類問題的小技巧優(yōu)先用官方驅(qū)動不要用第三方萬能驅(qū)動。FTDI的驅(qū)動對FT232R/FT231X支持很完善Silicon Labs的CP2102N驅(qū)動也比較干凈。裝了驅(qū)動后在設(shè)備管理器里看端口號是否出現(xiàn)、驅(qū)動版本是否匹配。如果設(shè)備在設(shè)備管理器里顯示未知設(shè)備先用USB Device Tree Viewer去看設(shè)備到底有沒有成功枚舉——它能顯示設(shè)備處于什么狀態(tài)、拿到了什么地址、配置描述符解析是否正常。如果是枚舉成功了但驅(qū)動沒加載那是驅(qū)動問題如果連配置都沒有那是設(shè)備端問題。抓包分析用Wireshark加USBPcap。很多人以為Wireshark只能抓網(wǎng)絡(luò)包其實它配合USBPcap可以抓USB總線上的URBUSB Request Block能看到主機發(fā)了什么請求、設(shè)備回了什么數(shù)據(jù)。排查枚舉失敗時非常有用。我舉一個真實的排查案例一塊板子的USB虛擬串口在Windows 10上穩(wěn)定但升級到Windows 11后偶發(fā)斷連。用Wireshark抓包發(fā)現(xiàn)新系統(tǒng)會周期性發(fā)送Get Status請求設(shè)備端響應(yīng)偶爾超過150ms超時于是主機把設(shè)備斷開重枚舉。最后定位是USB中斷服務(wù)函數(shù)里有一個耗時很長的Flash擦除操作擦除期間USB中斷被屏蔽了請求得不到及時響應(yīng)。把Flash擦除拆成多段、每段之間開中斷問題解決。這個案例正好能說明USB的不確定性很多時候不是USB本身的問題而是系統(tǒng)里其他設(shè)備的時序問題傳染給了USB。4.4 Host、Device、OTG三模式的區(qū)別與選擇關(guān)于USB Host模式、Device模式和OTG很多新手容易混淆。直接說結(jié)論Host模式負責(zé)供電、管理枚舉類似電腦那端接口用A型口Device模式是被動響應(yīng)類似U盤、手機那端接口用B型口或Micro-BOTG則在一條線纜上通過ID引腳識別自己是Host還是Device適合手機、平板這種需要角色動態(tài)切換的設(shè)備。嵌入式產(chǎn)品選型時如果只是給PC當(dāng)外設(shè)用Device模式即可STM32F407這類MCU的USB模塊做虛擬串口非常方便。如果需要直接插U盤、鍵鼠就得用Host模式這時候要考慮VBUS供電能力、根集線器開銷和驅(qū)動棧復(fù)雜度會上升一個量級。OTG模式適合既想連PC又想插U盤的產(chǎn)品但要注意ID引腳的檢測邏輯以及角色切換時總線的重新枚舉處理不好會出現(xiàn)插上電腦沒反應(yīng)、反插又不能用的怪問題。量產(chǎn)時我通常建議固定角色的產(chǎn)品不要用OTG直接按Host或Device設(shè)計能省掉一半的疑難雜癥。5. 三個子系統(tǒng)聯(lián)動時的不確定性傳染5.1 USB OTG燒寫Flash量產(chǎn)場景下的鏈路梳理搜索熱詞里有一條USB OTG燒寫NAND Flash這確實是量產(chǎn)和售后經(jīng)常會用到的形式主機通過USB把固件發(fā)給設(shè)備設(shè)備里的Bootloader再把固件寫入NOR/NAND Flash。這里面每一環(huán)都帶著前面幾章講到的不確定性很容易做個所謂燒錄成功率99%的上位機結(jié)果現(xiàn)場就是不停有人燒錄失敗。我建議把整條鏈路梳理成可觀測的環(huán)節(jié)再設(shè)計容錯USB枚舉是否成功、設(shè)備是否收到完整固件包CRC校驗、Flash擦寫是否完成WIP輪詢、寫入后回讀校驗是否通過。任何一個環(huán)節(jié)失敗都要有明確反饋和重試機制。我還習(xí)慣在燒錄協(xié)議里加入分塊序號CRC設(shè)計單塊失敗則重傳單塊而不是整包重傳Flash擦除采用按扇區(qū)擦除而不是整片擦除這樣即使掉電已傳完的分區(qū)還能保留支持斷點續(xù)傳。這套方案在代工廠和售后現(xiàn)場用下來燒錄失敗率從千分之一級別降到了幾乎不可見。5.2 共享SPI總線與電源域時的彼此干擾很多中型MCU只有1~2個SPI外設(shè)PSRAM和NOR Flash共用同一SPI總線、用不同CS片選的情況非常常見。這種方案省引腳但換來的是時序耦合。最大的坑是兩個設(shè)備對片選釋放后的保持時間要求不同PSRAM往往要求CS拉高后至少幾十納秒才能再次拉低而某些NOR Flash要求更長。如果你在寫完P(guān)SRAM后立刻切到Flash操作系統(tǒng)里又有其他中斷插入CS之間的間隔就可能不夠?qū)е翭lash識別到異常的SPI通信偶發(fā)地錯誤寫入或狀態(tài)寄存器被改。另外PSRAM是DRAM核心刷新期間對供電紋波比較敏感NOR Flash擦除時電流會突然沖高如果兩個器件共用一個LDO擦除瞬間的電流尖峰會把PSRAM的供電電壓拉低輕則刷新失敗丟數(shù)據(jù)重則系統(tǒng)復(fù)位。我通常會給它們分別配LDO或至少加大Bulk電容并在PCB布局上讓PSRAM的退耦電容盡量靠近電源引腳。5.3 一次USB枚舉把系統(tǒng)搞崩的排查實錄最后分享一個印象很深的聯(lián)調(diào)事故。設(shè)備上電后如果先讓PSRAM完成初始化再開USB一切正常但如果USB先被主機檢測到、枚舉中斷先來了而PSRAM還沒初始化完系統(tǒng)就會在USB中斷服務(wù)里訪問未初始化的PSRAM觸發(fā)總線錯誤直接HardFault。排查時一開始完全沒頭緒現(xiàn)象是偶發(fā)死機且發(fā)生在插拔USB時。后來在HardFault中斷里打印出出錯地址發(fā)現(xiàn)出錯地址落在PSRAM映射區(qū)域內(nèi)才把矛頭指向初始化順序。修復(fù)方案有兩種要么在PSRAM初始化完成前不使能USB中斷要么在USB中斷處理里加一個PSRAM就緒標志的保護。我最后選了第二種因為對系統(tǒng)啟動時間更友好。同時還加了一個調(diào)試開關(guān)可以在初始化階段通過串口打印每個外設(shè)的就緒狀態(tài)避免再次出現(xiàn)這種無聲無息的初始化順序問題。這個案例很能說明三個子系統(tǒng)單獨看都沒問題湊在一起就會出現(xiàn)不確定性傳染。排障的時候不要只盯著USB協(xié)議棧也要看它調(diào)用的資源內(nèi)存、Flash、時鐘是不是還沒準備好。6. 排查方法論與避坑速查表6.1 把玄學(xué)變成科學(xué)的四個步驟這類多外設(shè)聯(lián)動的不確定性問題最忌憑感覺改代碼。我總結(jié)了一套流程按順序執(zhí)行大部分問題都能收斂。第一步固定現(xiàn)場。復(fù)現(xiàn)異常時記錄供電電壓、環(huán)境溫度、固件版本、操作序列最好能截圖或錄屏。不能復(fù)現(xiàn)的問題先不要動代碼先想清楚當(dāng)時的輸入條件。第二步分層隔離。把系統(tǒng)切成獨立模塊逐層驗證。USB枚舉失敗先查設(shè)備端能否單獨枚舉成功再查驅(qū)動再查協(xié)議Flash擦寫異常先單獨驗證Flash讀寫再驗證文件系統(tǒng)層不要一上來就懷疑某一層。第三步加觀測點。在代碼里加日志、狀態(tài)寄存器快照、錯誤計數(shù)。很多偶發(fā)問題其實是狀態(tài)被覆蓋了加上觀測點后能看到真正出錯的位置。觀測點要盡量輕量不要改變原有時序否則可能測不出來。第四步做對照實驗。改一個變量跑一批測試統(tǒng)計成功率。改兩個以上變量結(jié)果就很難歸因了。比如懷疑是PSRAM刷新問題還是USB驅(qū)動問題就分別做只跑PSRAM壓測和只跑USB枚舉測試對比數(shù)據(jù)。6.2 問題速查表癥狀、原因、排查手段下面這個表是我在項目群里經(jīng)常貼出來的基本覆蓋了這三個子系統(tǒng)的常見問題癥狀可能的不確定性來源建議排查手段上電后Flash ID讀錯或全F上電復(fù)位時間不夠、供電不穩(wěn)加大上電延時讀ID前先發(fā)復(fù)位指令校驗IDFlash擦除不成功寫不進去狀態(tài)寄存器寫保護SRP/BP位、WP#引腳被拉高讀狀態(tài)寄存器按需發(fā)解鎖命令檢查WP#硬件Flash擦寫偶發(fā)失敗系統(tǒng)死機擦寫時間超過預(yù)置延時、共享SPI總線沖突改成WIP輪詢最大超時兜底檢查CS切換間隔16MB以上Flash地址錯亂3字節(jié)/4字節(jié)地址模式切換遺漏確認芯片上電默認模式按芯片手冊發(fā)模式切換命令PSRAM初始化失敗/數(shù)據(jù)錯誤上電穩(wěn)定時間不足、Latency配置錯、模式位漏設(shè)增大穩(wěn)定延時讀ID校驗抓SPI波形比對命令序列PSRAM偶發(fā)花屏/數(shù)據(jù)錯亂DMA超時設(shè)置較短、共享總線干擾、電源紋波放寬DMA超時CS間隔加長檢查供電退耦USB枚舉偶爾失敗時鐘精度不足、D上拉時序不對、線纜過長換外部晶振檢查上拉使能時機換短線測試USB在Windows上嘆號描述符錯誤、驅(qū)動異常、供電不足用USB Device Tree Viewer查狀態(tài)抓Wireshark包量電流USB虛擬串口偶發(fā)斷連USB中斷響應(yīng)超時、系統(tǒng)其他任務(wù)占用時間過長檢查中斷服務(wù)耗時拆分長任務(wù)調(diào)整中斷優(yōu)先級USB OTG燒錄Flash失敗鏈路中未做CRC/分塊斷點、Flash擦寫沒確認上位機和固件都加CRC分塊重傳機制輪詢WIP確認6.3 我這些年用下來最順手的工具與習(xí)慣工具方面硬件上我建議備常用的邏輯分析儀至少16通道、100MHz以上、USB協(xié)議分析儀預(yù)算不足可以先用WiresharkUSBPcap替代、支持模擬/數(shù)字雙通道的示波器。軟件上USB Device Tree Viewer、Wireshark、總線抓取工具、串口調(diào)試助手這幾個常備。Flash和PSRAM排障時邏輯分析儀抓SPI波形基本一抓一個準比盲改代碼高效太多。習(xí)慣上我有幾個一直堅持的做法。第一所有外設(shè)初始化代碼都做成可配置、可打印狀態(tài)的調(diào)試接口跑起來后先看狀態(tài)再看現(xiàn)象。第二關(guān)鍵行為Flash擦寫、USB枚舉、PSRAM初始化都加超時監(jiān)控和錯誤上報寧可多打印幾行日志也不要讓錯誤被吞掉。第三凡是涉及延時的地方全部都寫成宏或配置文件方便做全溫區(qū)、全電壓測試時批量調(diào)整。最后也是最重要的遇到玄學(xué)問題先忍住不亂改按上面四步走絕大多數(shù)問題都能在一個小時內(nèi)定位到物理層面或協(xié)議層面的真實原因。我個人這幾年的體會是PSRAM、NOR Flash、USB這類標準外設(shè)之所以還讓人頭疼不是因為它們本身有多復(fù)雜而是因為它們各自的不確定性疊加在一起時會呈現(xiàn)出系統(tǒng)級的詭異現(xiàn)象。把每個子系統(tǒng)的物理原理、時序邊界吃透再配合結(jié)構(gòu)化的排查方法那些看似隨機的問題其實都能收斂成確定的Bug。最后再分享一個小技巧在所有涉及等待外設(shè)就緒的代碼里我都會留一個帶時間戳的日志把每個階段的等待時間打印出來。這樣在復(fù)現(xiàn)故障時只要看一眼日志就能知道到底是哪個環(huán)節(jié)的時間裕量不夠比抓瞎式排查快得多。希望這篇內(nèi)容能幫你在下個項目里少踩幾個坑。