1. 先搞清楚 -110 是誰遞出來的做嵌入式 Linux 的尤其是做 WiFi 模塊適配的基本都會在某塊板子上撞見mmc0: error -110 whilst initialising SDIO card這一行日志。我第一次見到它是在一塊國產(chǎn) SoC 的評估板上WiFi 模塊型號剛換驅(qū)動也剛合進(jìn)去開機(jī)跑十次能成三次剩下七次全部停在枚舉階段dmesg 里翻來覆去就是這一句。當(dāng)時第一反應(yīng)是驅(qū)動的問題折騰了兩天把驅(qū)動換回舊版本、換了固件、換了 nvram 配置最后發(fā)現(xiàn)是板子上 SDIO 的 1.8V 電源軌在瞬時負(fù)載下塌了。這件事之后我才算真正把wifi sdio -110 錯誤分析這套東西從頭捋了一遍。這篇內(nèi)容想做的事情很明確把-110這個錯誤碼從它的誕生點一路拆到最終現(xiàn)象講清楚它是誰返回的、什么時候返回、在 SDIO 通信的哪一環(huán)觸發(fā)然后給出一套我自己在項目里反復(fù)用過的分層排查方法。不管你是剛接手 WiFi 模塊適配的新人還是已經(jīng)在調(diào) SDIO 時序的老手都能從里面找到能直接抄的操作。整篇偏實戰(zhàn)涉及設(shè)備樹、內(nèi)核配置、調(diào)試開關(guān)、硬件量測這幾塊都會給到具體命令和參數(shù)。1.1 從錯誤碼到調(diào)用棧-110 就是 ETIMEDOUTLinux 內(nèi)核里的錯誤碼沿用了一套固定的負(fù)數(shù)體系-110對應(yīng)的就是ETIMEDOUT。你可以在內(nèi)核頭文件里直接查到grep -n ETIMEDOUT /usr/include/asm-generic/errno.h # define ETIMEDOUT 110注意這里有個容易混淆的點用戶態(tài)errno是正數(shù) 110內(nèi)核態(tài)函數(shù)返回值是負(fù)數(shù)-110。所以在內(nèi)核日志里看到的error -110翻譯成人話就是等超時了。那到底是誰在等、等什么、等了多久順著 MMC 子系統(tǒng)往下扒最短的一條鏈路大概是這樣上層驅(qū)動比如brcmfmac、rtl8xxxu、aic8800之類調(diào)用sdio_readb()或sdio_writel()SDIO 公共層把它封裝成一個或多個mmc_request交給mmc_wait_for_req()mmc_wait_for_req()把請求下發(fā)給 host 控制器驅(qū)動常見的是sdhci然后wait_for_completion()等一個完成量Host 控制器發(fā)命令、發(fā)數(shù)據(jù)理應(yīng)產(chǎn)生中斷中斷服務(wù)程序里complete()喚醒等待者如果指定時間內(nèi)沒有中斷到來超時分支觸發(fā)把mrq-cmd-error或mrq-data-error置成-ETIMEDOUT也就是-110。在sdhci這顆最常見的 host 控制器里超時打印通常有兩處。命令超時走定時器sdhci_timeout_timer打印mmc0: Timeout waiting for hardware interrupt.數(shù)據(jù)超時走sdhci_timeout_data_timer打印內(nèi)容類似但緊接著會 dump 一整塊寄存器mmc0: sdhci: SDHCI REGISTER DUMP mmc0: sdhci: Sys addr: 0x00000000 | Version: 0x00001002 mmc0: sdhci: Blk size: 0x00000200 | Blk cnt: 0x00000008 mmc0: sdhci: Argument: 0x00000... | Trn mode: 0x00000012 mmc0: sdhci: Present: 0x01f70000 | Host ctl: 0x00000007 ...這塊 dump 是排查的核心線索之一后面第 4 章會專門講怎么讀它。1.2 為什么偏偏是 SDIO 接口的 WiFi 模塊高發(fā)同樣掛在 SDIO 上的設(shè)備比如 SD 卡、eMMC、SDIO 藍(lán)牙穩(wěn)定性通常比 WiFi 模塊好一大截。原因不復(fù)雜WiFi 是這幾個里面最不像存儲設(shè)備的那一個。SD 卡和 eMMC 的數(shù)據(jù)流是塊設(shè)備模型讀寫有明確的分界請求之間相對規(guī)整。而 WiFi 模塊在 SDIO 上跑的是三層?xùn)|西命令層CMD52讀寫寄存器、數(shù)據(jù)層CMD53做塊傳輸、帶外中斷DAT1 上的 SDIO 中斷。一次 WiFi 掃描可能觸發(fā)幾十上百次 CMD53中間還夾著固件下載、nvram 寫入、中斷上報。請求密度高、突發(fā)性強(qiáng)、時序敏感任何一環(huán)抖一下都可能超時。更要命的是功耗。WiFi 模塊在發(fā)射瞬間的電流峰值可以到 300mA 甚至更高如果電源設(shè)計余量不足、退耦電容放得不夠電壓跌落會直接反映到 SDIO 的信號電平上。而很多硬件同事在畫板子的時候是拿平均功耗去算電源的峰值這一下就被忽略了。再疊加一層因素SDIO 的時鐘頻率。為了追吞吐很多人上來就寫max-frequency 50000000甚至開 UHS-I 模式跑到 100MHz 以上。頻率越高對走線阻抗、端接、驅(qū)動能力的要求就越苛刻邊界條件下出-110的概率也就越大。所以你會看到一種很典型的現(xiàn)象——同一份軟件換一塊板子就好了或者在實驗室好好的一到產(chǎn)線批量就零星報-110。2. SDIO 一次讀寫到底走過了哪些環(huán)節(jié)想把-110定位到具體環(huán)節(jié)得先把 SDIO 一次完整的傳輸拆開看。不然你只能看到超時了看不到在哪一步超時了排查就會變成碰運(yùn)氣。2.1 命令、響應(yīng)、數(shù)據(jù)的三段式時序SDIO 協(xié)議在物理層上和 SD 卡共享同一套機(jī)制一共用到三根信號線組CLK時鐘、CMD命令線、DAT0~DAT3數(shù)據(jù)線。一次操作大致分三段。第一段是命令段。Host 在CMD線上發(fā) 48 位的命令幀卡在收到后于規(guī)定時間內(nèi)回響應(yīng)。命令分兩類無響應(yīng)比如 CMD0、有響應(yīng)48 位短響應(yīng)或者 136 位長響應(yīng)。SDIO 的寄存器讀寫用的是 CMD52一個命令幀里就能帶地址和數(shù)據(jù)非常輕量塊傳輸用 CMD53命令幀里帶塊長度、塊數(shù)量、寄存器地址。第二段是響應(yīng)段。卡必須在規(guī)范規(guī)定的窗口內(nèi)把響應(yīng)拉回來這個窗口按時鐘周期計算。如果 host 在規(guī)定周期里沒采到響應(yīng)起始位硬件層面就是響應(yīng)超時軟件層看到的就是-110。第三段是數(shù)據(jù)段只有 CMD53 有。數(shù)據(jù)傳輸方向由命令里的 bit 決定讀的時候卡驅(qū)動 DAT 線寫的時候 host 驅(qū)動。數(shù)據(jù)段結(jié)束靠 CRC 狀態(tài)和結(jié)束位判定。數(shù)據(jù)線在傳輸期間是 busy 的卡會通過拉低 DAT0 表示我還沒準(zhǔn)備好這時候 host 必須等。三段之間還有間隙規(guī)范里叫 Ncr、Nrc 之類的時序參數(shù)都是按CLK周期定義的。這里有個關(guān)鍵結(jié)論時鐘頻率越高這些以周期計數(shù)的窗口在絕對時間上就越短對硬件邊沿質(zhì)量的要求就越嚴(yán)。這也是為什么降速能解決很多-110——它把時間窗口按比例放大了。2.2 誰在計時硬件超時與軟件超時是兩套東西很多人排查時會誤以為只有一個超時其實 SDIO 上有兩層超時在同時工作搞清楚它們的區(qū)別非常關(guān)鍵。第一層是硬件超時由 host 控制器和卡之間的時序規(guī)定決定。SDHCI 這類控制器里有個 Data Timeout Counter值是根據(jù)當(dāng)前SDCLK頻率算出來的。核心代碼大致是/* drivers/mmc/host/sdhci.c 里的思路 */ count sdhci_calc_timeout(host, cmd, too_big);計算邏輯是拿期望的超時時間去除以時鐘周期再取 2 的冪次。這里有個容易踩的坑timeout 寄存器的值域很小最大只能表示到 2 的某次冪。如果當(dāng)前時鐘頻率太低、而要等的絕對時間又太長算出來的 count 就會溢出內(nèi)核會打印mmc0: Too large timeout 0x%x requested for CMD%d!看到這行說明你的時鐘低到了不正常的程度或者有人手動改了超時參數(shù)。第二層是軟件超時在 MMC 核心層。mmc_wait_for_req_done()會用一個固定的毫秒數(shù)去wait_for_completion_timeout()等不到就返回失敗。這一層是兜底防止硬件層面徹底死掉的時候內(nèi)核永遠(yuǎn)卡住。所以你在日志里可能看到兩種措辭Timeout waiting for hardware interrupt主機(jī)控制器定時器先到和request timeout核心層軟件等待先到。這兩個指向的排查方向不完全一樣。2.3 不同階段超時的日志長相日志是分階段定位的第一手證據(jù)。我把常見的幾種面貌列一下方便你對照。枚舉階段的失敗通常長這樣mmc1: new high speed SDIO card at address 0001 mmc1: error -110 whilst initialising SDIO card有時候前面會先有一行mmc1: Timeout waiting for hardware interrupt。這種情況說明卡已經(jīng)被識別到address 0001拿到了但是在后續(xù)功能初始化的時候掛了。固件下載階段的失敗往往在 WiFi 驅(qū)動的日志里brcmfmac: brcmf_sdio_download_firmware: dongle nvram file download failed brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout mmc1: Timeout waiting for hardware interrupt.這類錯誤的特點是枚舉過了接口通了但是大塊數(shù)據(jù)傳輸?shù)臅r候崩。運(yùn)行階段隨機(jī)抽風(fēng)日志零散且沒有規(guī)律mmc1: card 0001 removed mmc1: new high speed SDIO card at address 0001 wlan0: firmware crashcard removed后面緊跟new ... card是卡被重新枚舉了一次說明 host 控制器或者驅(qū)動判定卡掉線了。這種通常和電源瞬態(tài)或者信號完整性有關(guān)。休眠喚醒階段日志會出現(xiàn)在 resume 之后mmc1: Timeout waiting for hardware interrupt. mmc1: error -110 whilst initialising SDIO card這類問題八成和電源管理有關(guān)尤其是mmc-pwrseq和keep-power-in-suspend沒配好的時候。3. 按階段切分把問題圈死在某一層有了上面的日志分類第一步就不是急著改代碼而是先確定問題落在哪個階段。這個判斷做完能省掉一大半無效嘗試。3.1 枚舉階段CMD5 之后就不動了SDIO 卡的枚舉流程是CMD0 復(fù)位 → CMD5 查詢 IO 能力 → CMD3 拿到 RCA → CMD7 選中 → CMD52 讀寫 CCCR 寄存器 → 使能功能。如果-110出現(xiàn)在枚舉階段重點懷疑兩個方向。一是CMD5 的響應(yīng)超時。CMD5 是 SDIO 獨有的命令卡必須在規(guī)定時間內(nèi)回響應(yīng)。如果卡本身沒上電、復(fù)位沒釋放、或者 3.3V 電源還沒穩(wěn)那 CMD5 必然超時。這時候你要做的第一件事是量電源而不是改代碼。我在項目里遇到過一次mmc-pwrseq里的post-power-on-delay-ms只寫了 10ms而模塊手冊要求至少 100ms結(jié)果就是十次里成功三次。二是CMD52 讀寫 CCCR 失敗。這一步已經(jīng)在用 1 位總線通信了如果還超時說明信號質(zhì)量或者時鐘已經(jīng)出了問題。此時可以嘗試把max-frequency降到 400kHz 再試一次。400kHz 是 SD 規(guī)范里定義的識別階段默認(rèn)時鐘絕大多數(shù)硬件在這個頻率下都能通。如果 400kHz 還通不過那基本可以判定是硬件問題軟件怎么調(diào)都白搭。3.2 固件下載階段寫塊寫到一半崩WiFi 模塊尤其是 Broadcom、Realtek 那幾家的方案上電后需要 host 把固件和配置寫進(jìn)模塊內(nèi)存再啟動 CPU。這個過程通常幾萬到幾十萬字節(jié)靠 CMD53 分塊傳輸完成。這一階段出-110通常有三個原因第一個是塊大小設(shè)置不合理。SDIO 的塊大小受 CCCR 里的 FBRFunction Basic Register限制最大一般是 512 字節(jié)。但實際能跑多大還要看 host 控制器的能力和板級信號質(zhì)量。有些驅(qū)動默認(rèn)用 512實測在邊界板子上必須降到 256 甚至 128 才穩(wěn)。第二個是總線寬度。初始化階段通常用 1 位總線功能使能后切到 4 位。切換動作本身涉及寫 CCCR 的 Bus Interface Control 寄存器如果切換失敗或者切完沒生效后續(xù)大塊傳輸會異常。第三個是電源瞬態(tài)。固件下載是一個長時間高負(fù)載過程模塊電流持續(xù)在幾十毫安到上百毫安如果用的 LDO 響應(yīng)慢中間可能掉一下表現(xiàn)就是傳到一半超時。/* 一個比較保守的 WiFi 節(jié)點配置示例 */ sdmmc1 { status okay; bus-width 4; max-frequency 25000000; non-removable; cap-sdio-irq; keep-power-in-suspend; no-1-8-v; mmc-pwrseq wifi_pwrseq; vmmc-supply vcc_wifi; vqmmc-supply vcc_io; }; wifi_pwrseq: wifi-pwrseq { compatible mmc-pwrseq-simple; reset-gpios gpio1 29 GPIO_ACTIVE_LOW; post-power-on-delay-ms 200; power-off-delay-us 20000; };這套配置我一般拿來做基線。確認(rèn)能穩(wěn)定跑起來之后再逐項往上加頻率、加特性。3.3 運(yùn)行階段隨機(jī)抽風(fēng)最難纏運(yùn)行階段出-110是最讓人頭疼的因為不可復(fù)現(xiàn)。可能跑一整天沒事也可能半小時來一次。這類問題我總結(jié)下來絕大多數(shù)不落在協(xié)議層而落在環(huán)境上。一個典型的場景是中斷風(fēng)暴。WiFi 模塊在 SDIO 的 DAT1 線上發(fā)中斷如果 host 這邊的 IRQ 處理不當(dāng)或者模塊固件在高負(fù)載下瘋狂上報DAT1 會長時間處于低電平導(dǎo)致數(shù)據(jù)線被占住。這種時候你會看到寄存器 dump 里 DAT0~DAT3 的狀態(tài)位一直不變。另一個場景是并發(fā)沖突。有些方案藍(lán)牙和 WiFi 共用一根 SDIO 總線SDIO 上掛兩個 function如果兩個驅(qū)動的 runtime PM 沒有協(xié)調(diào)好一個在做 suspend 另一個在傳輸就會出現(xiàn)請求超時。這種情況要去看mmc_pm的日志或者干脆先關(guān)掉 runtime PM 驗證一次。最后一個高頻原因是供電紋波。前面提過 WiFi 發(fā)射瞬間的電流峰值如果此時 SDIO 恰好也在傳輸電壓跌落會直接打亂時序。這個問題在實驗室輕負(fù)載下看不出來一上產(chǎn)線跑壓力測試就批量冒出來。3.4 休眠喚醒階段resume 后第一槍就啞火休眠喚醒階段的-110有個很明顯的特征——系統(tǒng)睡下去之前一切正常醒來之后第一次訪問模塊就超時。根因基本集中在兩處。第一處是電源在 suspend 期間被切掉了但驅(qū)動層面不知道卡已經(jīng)掉電醒來后直接發(fā)命令卡當(dāng)然不回。解決辦法是配好keep-power-in-suspend保持供電或者配好mmc-pwrseq讓它在 resume 時重新走一遍上電時序。第二處是resume 時序競爭。電源恢復(fù)了但模塊內(nèi)部還在啟動此時 host 已經(jīng)開始發(fā)命令。這個窗口期要靠post-power-on-delay-ms拉開。我一般會把初期調(diào)試的值直接給到 200ms確認(rèn)穩(wěn)定后再往下壓到手冊標(biāo)稱的最小值加 30% 余量。4. 硬件側(cè)電源、時鐘、走線這三件事軟件調(diào)到底還是解決不了的時候就要回到硬件。根據(jù)我的經(jīng)驗-110里真正根因在硬件的比例比大多數(shù)人想象的要高得多。4.1 供電與上電時序先看三個電源參數(shù)VDD模塊主電源通常 3.3V、VDDIOIO 電源可能 3.3V 或 1.8V、以及復(fù)位信號。量測方法很直接把示波器調(diào)到電源軌上觸發(fā)條件設(shè)成下降沿閾值設(shè)在標(biāo)稱值的 90%然后讓 WiFi 跑起來。觀察有沒有瞬時跌落。判定標(biāo)準(zhǔn)不是平均電壓對不對而是最低點有沒有跌破模塊手冊的 minimum 值。我見過一個典型案例3.3V 軌在 WiFi 發(fā)射瞬間掉到 2.9V掉的時間只有幾微秒萬用表完全看不出來但 SDIO 時序已經(jīng)被打亂了。解決辦法是在模塊電源腳旁邊補(bǔ)一顆 22uF 陶瓷電容加一顆 1uF 高頻電容位置盡量靠近引腳。上電時序也是重災(zāi)區(qū)。模塊手冊一般會規(guī)定VDD穩(wěn)定后至少 N 毫秒才能釋放復(fù)位復(fù)位釋放后至少 M 毫秒才能通信。這兩段時間在設(shè)備樹里分別對應(yīng)post-power-on-delay-ms和mmc-pwrseq的時序控制。千萬不要憑感覺寫一個 10ms 就算完一定要查手冊或者實測。注意有些模塊的復(fù)位腳是低有效有些是高有效設(shè)備樹里GPIO_ACTIVE_LOW和GPIO_ACTIVE_HIGH寫反了現(xiàn)象就是永遠(yuǎn)枚舉不過。這個坑很基礎(chǔ)但很常見。4.2 時鐘頻率與驅(qū)動能力max-frequency是設(shè)備樹里最能直接影響穩(wěn)定性的一項。它的取值要和三個東西匹配host 控制器的能力、模塊支持的最高頻率、以及板級走線質(zhì)量。調(diào)試策略是從低往高試試跑頻率適用場景說明400kHz最小驗證識別階段默認(rèn)頻率幾乎必通12.5MHz保底可用吞吐偏低但穩(wěn)定性最好25MHz常規(guī)選擇大多數(shù)板子在 4 位總線下能跑通50MHz高性能需要走線阻抗控制良好100MHzUHS-I對硬件和電源要求都極高除了頻率還有一項容易被忽略的是時鐘相位phase和驅(qū)動能力drive strength。不少 SoC 的 SDIO 控制器支持調(diào)節(jié)這兩項通過 pinctrl 或者專門的寄存器配置。當(dāng)走線比較長超過 5cm的時候適當(dāng)調(diào)整采樣相位往往能救回一批板子。/* 調(diào)整時鐘相位的典型寫法具體屬性名取決于 SoC */ sdmmc1 { pinctrl-names default, state_uhs; pinctrl-0 sdmmc1_b4_pins_a; pinctrl-1 sdmmc1_b4_od_pins_a; };4.3 走線與信號完整性走線這塊軟件工程師通常插不上手但你有必要知道該向硬件提什么要求。CLK是最關(guān)鍵的一根。它是單向的從 host 到卡全程應(yīng)該做阻抗控制參考地完整。CLK上的過沖和振鈴會直接導(dǎo)致采樣錯誤。CMD和DAT0~3是雙向的需要上下拉。SDIO 規(guī)范里要求 host 側(cè)提供上拉如果板子上漏了信號在空閑態(tài)就會浮空表現(xiàn)是隨機(jī)超時。等長也很重要。4 位模式下DAT0~3加CMD這五根線的長度差要控制住具體數(shù)值看你的目標(biāo)頻率。25MHz 以下可以放寬到 5mm 以內(nèi)50MHz 就要壓到 2mm 級別。最后一個實用技巧如果你懷疑信號完整性問題可以先降頻驗證再飛線驗證。降頻能讓問題消失基本就鎖定是信號問題如果再換一塊 PCB 就好了那就是板廠工藝波動。5. 軟件側(cè)調(diào)參與設(shè)備樹逐項過硬件排查完還是一頭霧水的時候軟件側(cè)還有不少能擰的旋鈕。這一章把設(shè)備樹屬性和內(nèi)核調(diào)試手段挨個過一遍。5.1 降速驗證法最省事的第一刀不管問題出在哪我建議第一刀永遠(yuǎn)是降速。理由很簡單它能用最小的代價把時序類問題和邏輯類問題分開。# 修改設(shè)備樹 max-frequency 后重新編譯 dtb # 從 50MHz 降到 25MHz再降到 12.5MHz make dtbs降速后如果問題消失了說明是時序或者信號相關(guān)如果降速后問題依舊那多半是邏輯配置問題比如 pwrseq 時序不對、功能沒使能、固件路徑錯。這一刀的性價比極高我?guī)缀趺看味枷茸?。降速驗證做完之后還有第二個驗證動作關(guān)掉 SDIO 中斷。sdmmc1 { /* 注釋掉這一行 */ /* cap-sdio-irq; */ };cap-sdio-irq打開時模塊通過 DAT1 發(fā)中斷給 host關(guān)掉之后走輪詢模式。如果關(guān)掉中斷后就不超時了說明問題出在中斷線路上重點去查 DAT1 的走線和上拉。5.2 設(shè)備樹里那些和 SDIO 穩(wěn)定性強(qiáng)相關(guān)的屬性我把實際項目里最常調(diào)的幾項整理成表附上取值邏輯。屬性常用取值影響bus-width1 或 44 位吞吐高但要求四根 DAT 都合格max-frequency25000000 起調(diào)直接決定時序余量non-removable加上避免 host 反復(fù)做卡檢測cap-sdio-irq視情況關(guān)掉可排除中斷線路問題keep-power-in-suspend視電源設(shè)計保持供電避免 resume 異常no-1-8-v視 IO 電平禁掉 1.8V 電壓切換mmc-pwrseq必配控制復(fù)位和上電延時disable-wp加上避免寫保護(hù)檢測干擾關(guān)于no-1-8-v多說一句。這一項是禁掉 1.8V 信令電壓切換。默認(rèn)情況下UHS-I 模式會把 IO 電壓從 3.3V 切到 1.8V 來換更高的速度。如果你的板子沒有做 1.8V 供電或者模塊不支持就一定要加上這一項。沒加的話host 會嘗試切換電壓切完通信直接崩日志就是一堆-110。5.3 抓現(xiàn)場debugfs 與 dynamic debug設(shè)備樹的配置是一回事跑起來之后當(dāng)前狀態(tài)是另一回事。想確認(rèn)實際生效的參數(shù)看 debugfs。# 掛載 debugfs如果還沒掛 mount -t debugfs none /sys/kernel/debug # 查看當(dāng)前總線狀態(tài)時鐘、總線寬度、時序模式 cat /sys/kernel/debug/mmc0/ios # 輸出示例 # clock: 50000000 Hz # vdd: 21 (3.3 ~ 3.4 V) # bus mode: 2 (push-pull) # chip select: 0 (dont care) # power mode: 2 (on) # bus width: 2 (4 bits) # timing spec: 2 (sd high-speed) # signal voltage: 0 (3.30 V) # driver type: 0 (driver type B)這個輸出很有用。如果signal voltage顯示 1.80V 而你的板子其實是 3.3V說明電壓切換出問題了。如果bus width顯示 1 位說明 4 位切換沒成功。再看 MMC 層的動態(tài)調(diào)試。只要內(nèi)核編譯時開了CONFIG_DYNAMIC_DEBUG就可以在運(yùn)行時打開某個文件或模塊的調(diào)試輸出# 打開 sdhci 的所有調(diào)試信息 echo module sdhci p /sys/kernel/debug/dynamic_debug/control # 打開 MMC 核心層 echo file core.c p /sys/kernel/debug/dynamic_debug/control # 打開 sdio 層 echo file sdio.c p /sys/kernel/debug/dynamic_debug/control # 查看當(dāng)前已打開的調(diào)試點 grep -c p /sys/kernel/debug/dynamic_debug/control打開之后配合dmesg -w實時看日志能拿到比默認(rèn)詳細(xì)得多的信息包括每一次請求的地址、長度、方向。這個手段在做壓力測試抓偶發(fā)問題的時候特別有用。還有個更有針對性的一招用strace或者自己寫個腳本反復(fù)觸發(fā) WiFi 操作把復(fù)現(xiàn)概率拉高。#!/bin/sh # 壓力腳本反復(fù)掃描和連接放大偶發(fā)問題 while true; do iw dev wlan0 scan /dev/null 21 sleep 0.5 ping -c 2 -W 1 192.168.1.1 /dev/null 21 sleep 0.5 done我之前遇到一個半天才復(fù)現(xiàn)一次的-110用這個腳本跑了二十分鐘就穩(wěn)定復(fù)現(xiàn)了。6. 常見問題速查表與我的踩坑記錄前面幾章講的是方法論這一章把實際高頻問題整理成速查表再補(bǔ)幾個印象比較深的案例。6.1 常見問題速查表現(xiàn)象大概率原因快速驗證方法處理方向每次開機(jī)必報-110上電時序或復(fù)位查 pwrseq 的 delay 值加大post-power-on-delay-ms十次里成幾次電源余量不足示波器量電源軌最低點補(bǔ)退耦電容、換 LDO降速后正常信號完整性把頻率降到 12.5MHz查走線、調(diào)相位、調(diào)驅(qū)動能力關(guān)中斷后正常DAT1 中斷線路去掉cap-sdio-irq查 DAT1 上拉和走線只在高溫下報錯器件溫漂加熱臺升溫測試換器件或降低工作頻率resume 后報錯電源被切但驅(qū)動不知情看 suspend 期間電流配keep-power-in-suspend大塊傳輸才報錯塊大小或總線寬度把 block size 降到 128調(diào) CCCR 配置或驅(qū)動參數(shù)并發(fā)時隨機(jī)報錯runtime PM 競爭關(guān)掉 runtime PM 測試協(xié)調(diào)兩個 function 的 PM6.2 幾個印象深刻的坑第一個坑是關(guān)于mmc-pwrseq的。有一次項目上換了新模塊代碼完全照搬舊模塊的設(shè)備樹結(jié)果新模塊十次開機(jī)只成功兩次。查了兩天最后發(fā)現(xiàn)舊模塊的復(fù)位是高有效新模塊是低有效設(shè)備樹里那個GPIO_ACTIVE_LOW沒改導(dǎo)致復(fù)位電平一直是反的。改完之后問題立刻消失。教訓(xùn)是換模塊的第一步是逐項核對硬件差異表不要想當(dāng)然地復(fù)用配置。第二個坑是關(guān)于-110和塊大小的關(guān)系。某方案默認(rèn)塊大小 512 字節(jié)實驗室跑了三天沒問題。一到客戶現(xiàn)場同樣的板子開始零星報-110而且都是運(yùn)行一段時間之后。后來發(fā)現(xiàn)是客戶環(huán)境溫度比實驗室高十幾度高溫下信號裕量變小512 字節(jié)的長傳輸更容易在中間出錯。把塊大小降到 256問題解決。這類環(huán)境差異觸發(fā)的邊界問題最容易被忽略因為它不改變軟件邏輯只是把硬件裕量壓到了臨界點。第三個坑關(guān)于寄存器 dump 的讀法。很多人看到Timeout waiting for hardware interrupt后面那一大坨 dump 就直接跳過其實里面信息量很大。重點看Present這一行也就是 PRNSTS 寄存器。里面有幾個關(guān)鍵位如果CMD Inhibit位一直是 1說明命令還在發(fā)host 沒收到響應(yīng)如果DAT Inhibit位一直是 1說明數(shù)據(jù)線還被占著卡沒釋放總線如果Command Complete位沒置起來說明卡壓根沒回響應(yīng)如果這幾個位都在合理狀態(tài)但中斷沒來那可能是控制器自己的中斷屏蔽或者路由問題。我有一次就是靠讀Present寄存器發(fā)現(xiàn) DAT0 一直是低電平最后定位到是模塊的某個 GPIO 復(fù)用配置錯了把 DAT0 拉死了。第四個坑關(guān)于降速的假陽性。降速之后問題消失很容易讓人得出硬件沒問題軟件降速就行的結(jié)論。但如果這是批量產(chǎn)品降速意味著吞吐下降可能根本達(dá)不到產(chǎn)品要求。**降速只是定位手段不是最終方案。**正確的做法是降到能穩(wěn)定的頻率然后往上找到臨界點再回頭去優(yōu)化硬件讓臨界點提高上來。6.3 一份可以直接抄的排查流程最后把我自己用的排查順序整理出來從零開始遇到-110可以照這個走。第一步抓完整日志。dmesg -w全程掛著復(fù)現(xiàn)一次把從卡識別到報錯的所有行完整保存。特別注意報錯前的最后幾條那是關(guān)鍵。第二步判斷階段?？词敲杜e階段、固件下載階段、運(yùn)行階段還是 resume 階段。這一步?jīng)Q定后面往哪個方向走。第三步降速驗證。把max-frequency降到 12.5MHz重啟測試。如果好了走信號完整性方向如果還壞走配置方向。第四步關(guān)中斷驗證。去掉cap-sdio-irq重啟測試。用來區(qū)分是數(shù)據(jù)通道問題還是中斷通道問題。第五步量電源。示波器掛上主電源軌觸發(fā)在下降沿跑壓力測試?？醋畹忘c和持續(xù)時間。第六步看寄存器 dump。重點看Present和Error兩個狀態(tài)寄存器判斷是命令階段掛還是數(shù)據(jù)階段掛。第七步換板對比。同一份軟件換一塊板子如果換板就好那基本可以定性為硬件批次差異走硬件方向。這七步走完絕大多數(shù)-110都能有個明確的歸屬。剩下的極少數(shù)通常是多因素疊加比如電源和信號問題同時存在那就需要一項一項隔離工作量會大一些但思路是一樣的。我自己踩過的這些坑告訴我一件事-110這個錯誤碼本身不含任何指向性它只是說超時了。真正有價值的線索全在它前后的日志、寄存器狀態(tài)和你能測到的物理信號里。與其花時間猜不如花時間把這些證據(jù)收齊。收齊了答案往往就擺在那里。