簡(jiǎn)介面向Airoha洛達(dá)AB1568藍(lán)牙耳機(jī)應(yīng)用開(kāi)發(fā)的PDF技術(shù)文檔適合TWS耳機(jī)固件、嵌入式藍(lán)牙開(kāi)發(fā)及方案定制崗位的工程師與進(jìn)階學(xué)習(xí)者用于建立從硬件啟動(dòng)到應(yīng)用層功能落地的完整知識(shí)框架。壓縮包內(nèi)僅含1個(gè)PDF文件大小約9.58MB內(nèi)容按工程專(zhuān)題組織覆蓋上電執(zhí)行函數(shù)、mk文件宏定義、app活動(dòng)行為、ANC模式切換、LED呼吸燈、充電參數(shù)監(jiān)測(cè)、超時(shí)與事件管理、Airoha API、回調(diào)注冊(cè)、自動(dòng)關(guān)機(jī)、配對(duì)時(shí)間、開(kāi)機(jī)提示電量、清除配對(duì)列表、鏈路重連、UI Shell、SideTone、音頻路徑、DUT測(cè)RF、硬件復(fù)位、PEQ及通話降噪等模塊。已有374人學(xué)習(xí)可作為項(xiàng)目開(kāi)發(fā)與調(diào)試時(shí)按問(wèn)題檢索的參考手冊(cè)。其目錄結(jié)構(gòu)將芯片啟動(dòng)、事件驅(qū)動(dòng)、降噪算法與低功耗配置串聯(lián)起來(lái)便于讀者對(duì)照接口文檔和模塊實(shí)現(xiàn)排查細(xì)節(jié)、補(bǔ)齊知識(shí)短板適合作為開(kāi)發(fā)過(guò)程中的案頭查詢(xún)資料。1. 一個(gè)按鍵按下去為什么要在四個(gè)模塊里繞一圈做 Airoha AB1568 藍(lán)牙耳機(jī)開(kāi)發(fā)最容易翻車(chē)的不是降噪算法而是一條按鍵事件到底走了幾層才落到濾波器上。三連擊 POWER 鍵提示音響了模式也切了耳朵里卻一點(diǎn)變化都沒(méi)有——這個(gè)現(xiàn)象背后壓著三件事編譯期的宏有沒(méi)有把代碼編進(jìn)去、UI Shell 的活動(dòng)有沒(méi)有收到這條事件、NVR 里的參數(shù)有沒(méi)有真的寫(xiě)進(jìn)芯片。把這三層拆開(kāi)看耳機(jī)固件的黑匣子就打開(kāi)了一半剩下的都是細(xì)節(jié)。2. 上電第一行代碼宏在哪個(gè) mk 文件里決定哪段代碼存在很多人調(diào)固件的第一反應(yīng)是打開(kāi)工程找main然后發(fā)現(xiàn)自己改的那段代碼根本沒(méi)有被編譯。AB1568 的啟動(dòng)流程是兩段式的上電后先跑apps目錄下 bootloader 的main再由它把控制權(quán)交給apps下對(duì)應(yīng)工程earbuds或headset的main最后由apps_inits把各種應(yīng)用模塊拉起來(lái)。這條流水線上每一段都可能被條件編譯掐斷而決定掐不掐的那個(gè)開(kāi)關(guān)不在.c文件里在 GCC 目錄下的某個(gè) mk 文件里。理解這件事的價(jià)值在于它把你對(duì)“代碼為什么沒(méi)生效”的排查順序從“翻代碼”改成“先確認(rèn)這段代碼是否存在于最終鏡像”。嵌入式里最貴的 bug 不是邏輯寫(xiě)錯(cuò)而是邏輯壓根沒(méi)進(jìn)二進(jìn)制。2.1 兩段 main 的接力與條件編譯的斷點(diǎn)bootloader 的 main 負(fù)責(zé)的是很底層的事時(shí)鐘、電源、存儲(chǔ)介質(zhì)自檢然后判斷要不要進(jìn) FOTA 流程。這個(gè)判斷本身也是條件編譯的——只有在 GCC 目錄下的 mk 文件里定義了BL_FOTA_ENABLEbl_fota_process這個(gè)函數(shù)才會(huì)被編譯成真正的代碼。也就是說(shuō)你把升級(jí)邏輯寫(xiě)得再漂亮宏沒(méi)開(kāi)那段函數(shù)體在預(yù)處理階段就被整段抹掉了鏈接器連符號(hào)都看不見(jiàn)。常見(jiàn)的實(shí)現(xiàn)思路是mk 文件里的CFG_XXX y這類(lèi)寫(xiě)法最終會(huì)被構(gòu)建腳本翻譯成編譯命令行的-DXXX交給預(yù)處理器。所以“宏定義在哪里”這個(gè)問(wèn)題的答案永遠(yuǎn)是“在本次編譯實(shí)際引用的那個(gè) mk 文件里”而不是“在工程目錄里搜到的那個(gè)”。/* 這段代碼是否存在于固件取決于 BL_FOTA_ENABLE 是否在本次編譯的 mk 中被定義 */ #ifdef BL_FOTA_ENABLE /* 只有宏打開(kāi)時(shí)這個(gè)函數(shù)體才會(huì)被編譯器看到 */ bl_fota_process(); #endif上面這段沒(méi)有參數(shù)需要解釋重點(diǎn)在語(yǔ)義#ifdef之外是運(yùn)行時(shí)判斷#ifdef之內(nèi)是編譯期存在性判斷。前者錯(cuò)了能在 log 里看到分支沒(méi)走后者錯(cuò)了連 log 都不會(huì)有因?yàn)槟嵌未a不存在。這也是為什么“加了打印卻沒(méi)輸出”有時(shí)候根本不是串口問(wèn)題。進(jìn)到應(yīng)用層之后apps_inits統(tǒng)一初始化各應(yīng)用模塊其中就包含所有活動(dòng)行為的初始化。初始化順序在這里是有講究的誰(shuí)先注冊(cè)事件組誰(shuí)就能更早收到開(kāi)機(jī)階段拋出的廣播事件。順序不對(duì)你會(huì)看到某些模塊在開(kāi)機(jī)頭幾百毫秒里“反應(yīng)遲鈍”而幾百毫秒之后一切正常——這類(lèi)現(xiàn)象很容易被當(dāng)成玄學(xué)。2.2 build.sh list宏到底落在哪個(gè) mk同一套 SDK 里通常并存多個(gè)板級(jí)工程和多個(gè)產(chǎn)品工程編譯哪個(gè)工程、用哪個(gè) mk由構(gòu)建腳本的參數(shù)決定。先列出來(lái)看清楚比在目錄里翻文件可靠得多。# 列出當(dāng)前 SDK 支持的編譯目標(biāo)以及每個(gè)目標(biāo)實(shí)際引用的 mk 文件 ./build.sh list # 輸出里重點(diǎn)看兩列工程名、對(duì)應(yīng)的 feature_xx.mk # 當(dāng)前頭戴耳機(jī)基于 ab1565_ab1568_evk 開(kāi)發(fā)板衍生 # 對(duì)應(yīng)到 ab1568_evk 板級(jí)下的 headset_ref_desgin 工程 # 該工程編譯時(shí)引用的是 feature_68_evk 這個(gè) mk命令本身只有一句關(guān)鍵是讀輸出的方式不要只看工程名匹配要看板級(jí)前綴。ab1565_ab1568_evk是開(kāi)發(fā)板名ab1568_evk是落到具體芯片型號(hào)的板級(jí)目錄產(chǎn)品工程名headset_ref_desgin只是它的一個(gè)子項(xiàng)。三者對(duì)不上你改的 mk 就不是本次編譯用的那個(gè)。確認(rèn)之后打開(kāi)feature_68_evk.mk能看到現(xiàn)成的宏定義也可以往里加新的。比如 ANC 相關(guān)的MTK_ANC_ENABLE在這個(gè)文件里已經(jīng)是開(kāi)啟狀態(tài)——這意味著 ANC 的按鍵處理分支是存在的問(wèn)題不可能出在“沒(méi)編進(jìn)去”這一層。這個(gè)判斷很省時(shí)間一次確認(rèn)直接排除掉一整類(lèi)可能性。2.3 增量編譯與 mk 變更的沖突改 mk 之后不 clean 就 build是血淚經(jīng)驗(yàn)級(jí)別的坑。構(gòu)建系統(tǒng)對(duì).c文件的依賴(lài)關(guān)系跟蹤得很細(xì)但對(duì) mk 文件的變更往往只做粗粒度判斷甚至完全依賴(lài)時(shí)間戳。結(jié)果就是宏已經(jīng)改了目標(biāo)文件卻沒(méi)重新生成你燒進(jìn)去的還是舊鏡像。# 改過(guò)任何 mk 文件之后的標(biāo)準(zhǔn)動(dòng)作 ./build.sh clean ./build.sh ab1568_evk headset_ref_desgin這兩條命令的含義很直白但順序不能省。clean清掉的是中間產(chǎn)物和最終鏡像確保下一次編譯完整展開(kāi)所有 mk。省掉它的代價(jià)是幾十分鐘的迷惑你明明改了宏行為卻一點(diǎn)沒(méi)變于是開(kāi)始懷疑芯片、懷疑工具鏈、懷疑人生。另外一個(gè)細(xì)節(jié)是宏的作用域。寫(xiě)在 mk 里的宏是全局的寫(xiě)在某個(gè)模塊自己的 mk 片段里的宏只影響該模塊。同一個(gè)宏名在兩處出現(xiàn)且值不同最終生效的取決于鏈接順序和包含順序這種沖突不會(huì)有任何警告。所以新增宏之前先在feature_68_evk.mk里搜一遍名字比事后查行為異常便宜得多。3. UI Shell 事件框架一條事件為什么所有活動(dòng)都能收到耳機(jī)固件里最像“操作系統(tǒng)”的部分就是這套 UI Shell。它把一個(gè)個(gè)界面抽象成活動(dòng)activity每個(gè)活動(dòng)有自己的事件組和處理函數(shù)。系統(tǒng)產(chǎn)生事件時(shí)不是點(diǎn)對(duì)點(diǎn)投遞而是把事件拋出去所有活動(dòng)都能監(jiān)聽(tīng)到屬于自己事件組的才處理。這個(gè)設(shè)計(jì)看著低效實(shí)際上解決了嵌入式 UI 里最麻煩的問(wèn)題狀態(tài)切換時(shí)的責(zé)任歸屬。3.1 活動(dòng)棧ui_shell_start_activity 申請(qǐng)的那個(gè) itemui_shell_start_activity做的事情是在活動(dòng)棧里申請(qǐng)一個(gè)空閑 item把活動(dòng)的描述結(jié)構(gòu)掛上去。這個(gè)棧決定了“誰(shuí)在前臺(tái)”。app_preproc_activity_proc是主進(jìn)程負(fù)責(zé)管理和調(diào)配其它子進(jìn)程比如app_home_screen_idle_activity_proc這類(lèi)具體界面。開(kāi)機(jī)后系統(tǒng)會(huì)拉起很多不同的進(jìn)程每個(gè)進(jìn)程里有不同的事件組形成一張扁平的監(jiān)聽(tīng)網(wǎng)。/* 活動(dòng)的事件處理表事件組 ID 與處理函數(shù)的對(duì)應(yīng)關(guān)系 */ static const ui_shell_event_handler_t home_screen_handlers[] { { KEY_EVENT_GROUP, app_home_screen_proc_key_event_group }, /* 按鍵類(lèi)事件 */ { ANC_EVENT_GROUP, app_home_screen_proc_anc_event_group }, /* ANC 狀態(tài)變化 */ { TIMER_EVENT_GROUP, app_home_screen_proc_timeout_event }, /* 超時(shí)類(lèi)事件 */ }; /* 啟動(dòng)活動(dòng)在活動(dòng)堆里申請(qǐng)一個(gè)空閑 item并把處理表注冊(cè)進(jìn)去 */ ui_shell_start_activity(app_home_screen_idle_activity_proc, home_screen_handlers, ARRAY_SIZE(home_screen_handlers), false);上面兩個(gè)調(diào)用的語(yǔ)義是先聲明“我關(guān)心哪幾類(lèi)事件、分別交給誰(shuí)處理”再聲明“我現(xiàn)在進(jìn)入活動(dòng)?！?。第三個(gè)參數(shù)是處理表長(zhǎng)度最后一個(gè)布爾量在不同 SDK 版本里可能是“是否獨(dú)占前臺(tái)”之類(lèi)的開(kāi)關(guān)入?yún)㈨樞蛞渤Ｓ姓{(diào)整理解成“注冊(cè)范圍 前臺(tái)聲明”這兩件事就夠了。真正要記住的是處理表在注冊(cè)時(shí)就被固定下來(lái)活動(dòng)運(yùn)行期間不會(huì)再變。3.2 事件的三段式send、init_input_msg、remove事件的生命周期被拆成三個(gè)明確的動(dòng)作。ui_shell_send_event負(fù)責(zé)投遞攜帶事件組、事件 ID、payload 大小和優(yōu)先級(jí)ui_shell_init_input_msg是接收側(cè)的統(tǒng)一入口把底層消息隊(duì)列里的事件取出來(lái)分派給活動(dòng)ui_shell_remove_event則是后悔藥——把還沒(méi)被消費(fèi)的事件從隊(duì)列里摘掉。/* 投遞一條按鍵事件不來(lái)自中斷、優(yōu)先級(jí)普通、屬于按鍵事件組 */ ui_shell_send_event(false, /* 是否來(lái)自中斷上下文 */ EVENT_PRIORITY_NORMAL, KEY_EVENT_GROUP, /* 事件組決定誰(shuí)來(lái)處理 */ KEY_EVENT_ANC_SWITCH, /* 事件 ID具體是什么事 */ payload, /* 附帶數(shù)據(jù)可為 NULL */ sizeof(payload), NULL, 0); /* 后悔藥場(chǎng)景已經(jīng)切換舊事件不該再被處理 */ ui_shell_remove_event(KEY_EVENT_GROUP, KEY_EVENT_ANC_SWITCH);參數(shù)里最關(guān)鍵的是事件組和事件 ID 的組合。事件組是路由依據(jù)事件 ID 是業(yè)務(wù)依據(jù)。同一個(gè)事件 ID 掛在不同事件組下會(huì)走到完全不同的處理函數(shù)這種“同名不同命”的情況在多人協(xié)作的工程里非常常見(jiàn)也是事件丟了的經(jīng)典原因。false這個(gè)參數(shù)表示調(diào)用上下文不是中斷如果你在中斷里直接發(fā)事件并傳true行為會(huì)更接近“延后到安全上下文處理”。傳錯(cuò)的后果不是崩潰而是偶發(fā)的、難復(fù)現(xiàn)的事件丟失。3.3 廣播式投遞的代價(jià)與邊界廣播的好處是解耦新增一個(gè)活動(dòng)不需要修改發(fā)送方。代價(jià)是每個(gè)活動(dòng)都要對(duì)不屬于自己的事件做一次快速丟棄而且“誰(shuí)在前臺(tái)誰(shuí)處理”這條隱含規(guī)則沒(méi)有被框架強(qiáng)制。當(dāng)兩個(gè)活動(dòng)同時(shí)存在于棧上、又都注冊(cè)了同一個(gè)事件組就會(huì)出現(xiàn)同一條按鍵被處理兩次的現(xiàn)象——比如降噪模式連跳兩格。ui_shell_remove_event的存在就是為了補(bǔ)這個(gè)洞在狀態(tài)切換的瞬間把上一條還沒(méi)被消費(fèi)完的事件摘掉避免它在新的上下文里被執(zhí)行。我一般會(huì)這么理解這套框架廣播負(fù)責(zé)“送達(dá)”活動(dòng)棧負(fù)責(zé)“當(dāng)前誰(shuí)該管”remove負(fù)責(zé)“別管過(guò)期的”。三者缺一個(gè)行為就會(huì)在某些邊角場(chǎng)景里歪掉。判斷一條事件有沒(méi)有人處理最直接的辦法是在ui_shell_init_input_msg的分派路徑上加一行 log打印事件組和事件 ID。有投遞記錄但沒(méi)有處理記錄說(shuō)明當(dāng)前棧上沒(méi)有活動(dòng)注冊(cè)該事件組兩者都有但業(yè)務(wù)沒(méi)反應(yīng)問(wèn)題就在處理函數(shù)內(nèi)部跟框架無(wú)關(guān)。這條分界線劃清楚排查效率會(huì)差好幾倍。4. ANC 模式切換從 key_action 到 ANC 濾波器組ANC 是耳機(jī)固件里鏈路最長(zhǎng)的一個(gè)功能它橫跨按鍵、事件框架、服務(wù)層和聲學(xué)參數(shù)四層。任何一層斷掉用戶聽(tīng)到的都是“沒(méi)效果”但從代碼上看每一層都“跑過(guò)了”。4.1 硬件通路FF、FB、FBC 和主麥各管什么音頻通路分 Line-in 和 BT 兩種輸入。降噪側(cè)用的是 FF 麥前饋朝外拾環(huán)境噪和 FB 麥反饋朝耳道拾殘余噪FBC 是 FB 的補(bǔ)償通路。整機(jī)上有 4 個(gè)麥克風(fēng)用于降噪另有 1 個(gè)主麥負(fù)責(zé)說(shuō)話拾音配 2 個(gè)振動(dòng)喇叭和 2 個(gè)聲音喇叭。分工很清楚ANC 降噪用 FF 和 FB通話降噪用 talk 麥加 FF。config tool 上有三個(gè)參數(shù)頁(yè)ANC含 FF 與 FB、FBC、Passthrough通透。它們和用戶感知的“模式”不是一一對(duì)應(yīng)關(guān)系模式是給用戶按的參數(shù)頁(yè)是給聲學(xué)工程師調(diào)的。一個(gè) ANC 模式背后會(huì)同時(shí)用到 ANC 頁(yè)和 FBC 頁(yè)的參數(shù)通透模式背后是 Passthrough 頁(yè)的參數(shù)。把這層關(guān)系理順才看得懂后面濾波器編號(hào)的分配邏輯。4.2 key_action 的四種語(yǔ)義與映射文件按鍵事件進(jìn)來(lái)后先進(jìn)_proc_key_event_group處理。這條路徑能不能走通前提是MTK_ANC_ENABLE已經(jīng)打開(kāi)——在feature_68_evk.mk里確認(rèn)過(guò)是開(kāi)的。所有 ANC 相關(guān)行為最終都收斂到app_home_screen_process_anc_and_pass_through這一個(gè)函數(shù)里靠key_action的值區(qū)分意圖。/* key_action 的四種語(yǔ)義對(duì)應(yīng) config tool 里配置的按鍵行為 */ switch (key_action) { case KEY_ANC: /* 單純 ANC 開(kāi) / 關(guān)不碰通透 */ target_anc_type (target_anc_type ANC_OFF) ? ANC_ON : ANC_OFF; break; case KEY_PASS_THROUGH: /* 單純通透開(kāi) / 關(guān) */ target_anc_type (target_anc_type PT_OFF) ? PT_ON : PT_OFF; break; case KEY_SWITCH_ANC_AND_PASSTHROUGH: /* 三段循環(huán)全關(guān) - 通透 - ANC */ target_anc_type next_in_cycle(target_anc_type); break; case KEY_BETWEEN_ANC_PASSTHROUGH: /* 兩段來(lái)回只在通透和 ANC 之間切 */ target_anc_type (target_anc_type ANC_ON) ? PT_ON : ANC_ON; break; } /* 模式和濾波器 ID 一起下發(fā)服務(wù)層據(jù)此選參數(shù)組 */ app_anc_service_enable(target_anc_type, target_filter_id);四個(gè)分支的差別不在代碼量而在狀態(tài)機(jī)的拓?fù)淙窝h(huán)有三個(gè)穩(wěn)定態(tài)兩段切換只有兩個(gè)。選錯(cuò)語(yǔ)義用戶按三下會(huì)回到原點(diǎn)或者卡在通透出不來(lái)——這類(lèi)“手感問(wèn)題”最后都會(huì)被當(dāng)成 bug 報(bào)上來(lái)。按鍵行為和key_action的綁定寫(xiě)在customerized_key_config.c里。這個(gè)文件是產(chǎn)品差異化的集中地不同客戶的長(zhǎng)按、雙擊、三連擊語(yǔ)義都在這里分叉。改這里之前先確認(rèn)MTK_ANC_ENABLE否則你會(huì)改了一個(gè)根本不會(huì)被編譯進(jìn)去的分支。4.3 app_anc_service_enable模式與濾波器枚舉的對(duì)應(yīng)服務(wù)層拿到target_anc_type和target_filter_id后去 NVR 里取對(duì)應(yīng)的參數(shù)組下發(fā)給 DSP。濾波器用枚舉表示AUDIO_ANC_CONTROL_ANC_FILTER_DEFAULT的值是 1AUDIO_ANC_CONTROL_PASS_THRU_FILTER_DEFAULT的值是 9。這兩個(gè)數(shù)字不是隨手寫(xiě)的它們對(duì)應(yīng) NVR 里參數(shù)塊的編號(hào)。NVR 里的濾波器按四組組織每組包含左右耳各一套組內(nèi)容說(shuō)明Filter 1FF1(L/R) FB1(L/R) FBC1(L/R)第一組 ANC 參數(shù)Filter 2FF2(L/R) FB2(L/R) FBC2(L/R)第二組 ANC 參數(shù)Filter 3FF3(L/R) FB3(L/R) FBC3(L/R)第三組 ANC 參數(shù)Filter 4FF4(L/R) FB4(L/R) FBC4(L/R)第四組 ANC 參數(shù)把 tool 界面上的 L 和 R 疊在一起看四組結(jié)構(gòu)的對(duì)稱(chēng)性就出來(lái)了。切換 ANC 模式時(shí)看 loganc_result里三個(gè)模式循環(huán)出現(xiàn)每次都會(huì)帶上當(dāng)前使用的 filter id。這個(gè)字段是排查“切了但沒(méi)效果”的第一手證據(jù)id 變了說(shuō)明鏈路通到了服務(wù)層沒(méi)變說(shuō)明卡在按鍵或狀態(tài)機(jī)。4.4 NVR 參數(shù)從 config tool 到芯片的那一段三連擊 POWER有提示音沒(méi)有降噪效果——這是最典型的一類(lèi)現(xiàn)象。原因往往極其樸素用 config tool 打開(kāi)工程的download目錄ANC 模式下的參數(shù)是空的。代碼路徑全對(duì)參數(shù)沒(méi)寫(xiě)DSP 拿到的是一組零。修復(fù)流程是把聲學(xué)調(diào)好的 ANC 參數(shù)nvr 文件導(dǎo)入工程或者直接在 tool 上調(diào)整然后先 Write NV 再 Reset把 FF、FB、FBC 和 AiroThru 參數(shù)寫(xiě)進(jìn)耳機(jī)。之后循環(huán)三連擊能聽(tīng)出不同模式的降噪差異才算真正打通。參數(shù)寫(xiě)進(jìn)去之后還需要能讀懂它。NVR 里的數(shù)值是高字節(jié)在前并且用有符號(hào)定點(diǎn)表示直接按十六進(jìn)制讀會(huì)得到離譜的結(jié)果。def parse_component_gain(word: str) - float: 解析 NVR 里的 component gain 字段返回 dB 值 # 芯片存儲(chǔ)是高字節(jié)在前先按字節(jié)反轉(zhuǎn) swapped bytes.fromhex(word)[::-1].hex() raw int(swapped, 16) # 有符號(hào) 16 位超過(guò) 0x7FFF 說(shuō)明是負(fù)數(shù)減 65536 還原 if raw 0x7FFF: raw - 0x10000 return raw / 100.0 # 單位是 0.1 dB換算成 dB # 以 0xE1E5 10FF 1400 D8DC D8DC 為例 print(parse_component_gain(10FF)) # -2.4 dB對(duì)應(yīng) component gain -240 print(parse_component_gain(1400)) # 0.2 dB對(duì)應(yīng) component gain 20關(guān)鍵在兩步字節(jié)反轉(zhuǎn)和有符號(hào)還原。10FF反轉(zhuǎn)成FF10十進(jìn)制是 65296減 65536 得 -240除以 100 就是 -2.4 dB。1400反轉(zhuǎn)成0014十進(jìn)制 20不用減直接是 0.2 dB。后面兩段D8DC D8DC按同樣的規(guī)則解讀字段順序照著 tool 里顯示的順序讀就行。這套解析邏輯值得單獨(dú)寫(xiě)成腳本的原因很實(shí)際調(diào)音階段你會(huì)反復(fù)對(duì)比“tool 里顯示的”和“芯片里存的”是否一致。手算一次兩次還行改十幾次參數(shù)之后必然出錯(cuò)而錯(cuò)的方向還挺隱蔽——正負(fù)號(hào)搞反降噪曲線就整條翻過(guò)來(lái)。5. 排查清單ANC 沒(méi)效果、宏不生效、參數(shù)回滾的五個(gè)常見(jiàn)坑這一章的五條記錄都來(lái)自實(shí)際調(diào)試現(xiàn)場(chǎng)共同點(diǎn)是代碼看起來(lái)沒(méi)問(wèn)題現(xiàn)象卻穩(wěn)定復(fù)現(xiàn)。每條按現(xiàn)象、原因、解決三段寫(xiě)方便對(duì)號(hào)入座。5.1 有提示音、沒(méi)降噪?yún)?shù)沒(méi)寫(xiě)進(jìn)芯片現(xiàn)象三連擊 POWER 鍵提示音響了log 里anc_result也在三個(gè)模式之間循環(huán)但左右耳聽(tīng)感完全沒(méi)變化。原因用 config tool 打開(kāi)工程download目錄ANC 模式下沒(méi)有參數(shù)。代碼路徑通了服務(wù)層也執(zhí)行了但下發(fā)給 DSP 的是一組全零系數(shù)。降噪算法在零系數(shù)下等價(jià)于直通所以“切了等于沒(méi)切”。解決導(dǎo)入聲學(xué)調(diào)好的 nvr 文件或者直接在 tool 上調(diào)整 ANC、FBC、Passthrough 三頁(yè)參數(shù)然后 Write NV再 Reset。重置這一步不能省部分參數(shù)在初始化階段才被讀取不 Reset 就只能等下次上電。驗(yàn)證方式是循環(huán)三連擊聽(tīng)感上能區(qū)分出不同模式的降噪強(qiáng)度差異。5.2 改了宏沒(méi)生效改的不是本次編譯的 mk現(xiàn)象在某個(gè) mk 文件里加了宏定義重新編譯燒錄行為毫無(wú)變化或者鏈接時(shí)報(bào)某個(gè)符號(hào)未定義。原因工程里存在多個(gè) mk 文件本次編譯實(shí)際引用的是另一個(gè)。比如產(chǎn)品工程是headset_ref_desgin板級(jí)前綴是ab1568_evk最終落到feature_68_evk這個(gè) mk而你改的是隔壁板級(jí)目錄下的同名文件。解決先跑./build.sh list從輸出里確認(rèn)工程名與 mk 的對(duì)應(yīng)關(guān)系再去改那個(gè)文件。改完必須 clean 再 build因?yàn)?mk 變更不一定觸發(fā)目標(biāo)文件重建。符號(hào)未定義這個(gè)報(bào)錯(cuò)反而是好事它至少告訴你“這段代碼確實(shí)被條件編譯切掉了”最怕的是行為靜默改變連報(bào)錯(cuò)都沒(méi)有。5.3 參數(shù)回滾只改了 download沒(méi)改 XML 和 bin現(xiàn)象參數(shù)在 tool 里調(diào)好了也 Write NV 驗(yàn)證過(guò)效果。重新編譯工程、燒錄之后ANC 又回到舊參數(shù)。原因Write NV 寫(xiě)的是耳機(jī)里的 NVR 區(qū)不是工程代碼。重新編譯會(huì)用工程里的 XML 和filesystem.bin重新生成download目錄把之前的改動(dòng)覆蓋掉。有一批 NV key 是存在filesystem.bin里的光改 XML 不換 bin參數(shù)只更新一半。解決用 Special_Export 導(dǎo)出變更到文件會(huì)得到 4 個(gè)文件用 Save 方式保存成 download 則是 3 個(gè)文件其中 syskey 和 bin 是一致的。把導(dǎo)出的syskey.xml里變更的 key 逐個(gè)更新到工程的幾個(gè)nvkey.xml中——注意syskey.xml里有的 keyIDnvkey.xml里不一定有沒(méi)有的要新增已有的要替換比如 ANC 參數(shù)涉及的0xEE00~0xEEFF段在nvkey.xml里就沒(méi)有。同時(shí)替換filesystem.bin再 clean build。5.4 按鍵無(wú)響應(yīng)事件發(fā)出去了沒(méi)人接現(xiàn)象按鍵 log 有ui_shell_send_event也調(diào)了處理函數(shù)里的斷點(diǎn)卻從不命中。換個(gè)界面再按偶爾又能響應(yīng)。原因事件是廣播的但只有當(dāng)前處于活動(dòng)棧前臺(tái)、且注冊(cè)了對(duì)應(yīng)事件組的活動(dòng)才會(huì)處理。當(dāng)前如果停在配對(duì)界面或產(chǎn)測(cè)界面home screen 的處理表根本沒(méi)參與分派。另一種情況是事件組 ID 用錯(cuò)發(fā)到了另一個(gè)組名下。解決在ui_shell_init_input_msg的分派路徑上打一行 log同時(shí)打印事件組和事件 ID對(duì)比活動(dòng)注冊(cè)表里的事件組。有投遞無(wú)分派就是路由問(wèn)題有分派無(wú)業(yè)務(wù)響應(yīng)才是處理函數(shù)的問(wèn)題。另外在狀態(tài)切換的地方補(bǔ)ui_shell_remove_event把過(guò)期事件摘掉避免它在新上下文里被誤執(zhí)行。5.5 超時(shí)時(shí)間不準(zhǔn)tick 單位和宏的換算現(xiàn)象自動(dòng)關(guān)機(jī)、配對(duì)超時(shí)、鏈路丟失重連這些功能實(shí)際觸發(fā)時(shí)間跟配置值對(duì)不上有時(shí)差好幾倍。原因配置項(xiàng)的單位是毫秒底層定時(shí)器按 tick 計(jì)數(shù)中間有一次換算。有人在宏里直接填了毫秒數(shù)卻沒(méi)走換算宏或者在改 tick 頻率之后忘了同步改配置值。解決把所有超時(shí)相關(guān)的宏集中看一遍確認(rèn)單位是毫秒還是 tick換算系數(shù)跟當(dāng)前 tick 頻率是否匹配。驗(yàn)證方式是掐表設(shè)一個(gè) 30 秒的超時(shí)實(shí)際測(cè)一次觸發(fā)點(diǎn)差一個(gè)數(shù)量級(jí)就是單位問(wèn)題差幾秒就是 tick 精度問(wèn)題。自動(dòng)關(guān)機(jī)還涉及關(guān)機(jī)前的提示音和 LED 狀態(tài)收尾時(shí)間設(shè)置過(guò)短會(huì)在提示音播到一半時(shí)斷電聽(tīng)感上像是“關(guān)機(jī)有雜音”。6. 參數(shù)固化還是 FOTA 下發(fā)NVKEY 的兩條路怎么選ANC 參數(shù)最終要落到耳機(jī)里有兩條路編譯進(jìn)固件或者通過(guò) FOTA 更新 NV key。兩者的取舍不在技術(shù)難度而在迭代節(jié)奏。維度固化到 XML/binFOTA 更新 NVKEY生效時(shí)機(jī)整包燒錄后生效單獨(dú)下發(fā)不用重?zé)碳a(chǎn)線適配量產(chǎn)程序直接編譯一致性好需要額外的下發(fā)工具鏈迭代速度慢每次改參數(shù)都要 clean build快適合調(diào)音階段反復(fù)試回滾成本重?zé)傧掳l(fā)一次舊參數(shù)調(diào)音階段我傾向于走 FOTA/Write NV 這條路改一次參數(shù)聽(tīng)一次效果不用等編譯。定版之后必須固化到 XML 和filesystem.bin讓產(chǎn)線拿到的每一臺(tái)耳機(jī)參數(shù)完全一致——參數(shù)固化到代碼里的價(jià)值不是“省事”而是“可復(fù)現(xiàn)”。驗(yàn)證是否真的固化了方法很樸素clean build 生成新的download用 config tool 打開(kāi)看 ANC 參數(shù)是不是剛才導(dǎo)入的那一版如果不是說(shuō)明 XML 沒(méi)更新全或者filesystem.bin沒(méi)替換。再狠一點(diǎn)的驗(yàn)證是把耳機(jī)擦除后重新燒錄讀回 NV key 跟預(yù)期值逐字節(jié)比對(duì)比肉耳聽(tīng)降噪靠譜得多。踩過(guò)一次坑之后我就養(yǎng)成了習(xí)慣每次改 NV 參數(shù)先問(wèn)自己一句“這是要驗(yàn)證還是要定版”驗(yàn)證走 Write NV定版走 Special_Export XML/bin 替換兩條路絕不混用。混用的后果是某天發(fā)現(xiàn)倉(cāng)庫(kù)里的參數(shù)和產(chǎn)線耳機(jī)對(duì)不上而沒(méi)人記得是哪次改的。從那以后我每次動(dòng) NV key 都強(qiáng)制走一遍“導(dǎo)出、更新 XML、替換 bin、clean build、tool 復(fù)核”這五步一步不跳。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取