簡介面向Airoha洛達(dá)AB1568藍(lán)牙耳機(jī)應(yīng)用開發(fā)的PDF技術(shù)文檔適合TWS耳機(jī)固件、嵌入式藍(lán)牙開發(fā)及方案定制崗位的工程師與進(jìn)階學(xué)習(xí)者用于建立從硬件啟動(dòng)到應(yīng)用層功能落地的完整知識(shí)框架。壓縮包內(nèi)僅含1個(gè)PDF文件大小約9.58MB內(nèi)容按工程專題組織覆蓋上電執(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í)間、開機(jī)提示電量、清除配對(duì)列表、鏈路重連、UI Shell、SideTone、音頻路徑、DUT測(cè)RF、硬件復(fù)位、PEQ及通話降噪等模塊。已有374人學(xué)習(xí)可作為項(xiàng)目開發(fā)與調(diào)試時(shí)按問題檢索的參考手冊(cè)。其目錄結(jié)構(gòu)將芯片啟動(dòng)、事件驅(qū)動(dòng)、降噪算法與低功耗配置串聯(lián)起來便于讀者對(duì)照接口文檔和模塊實(shí)現(xiàn)排查細(xì)節(jié)、補(bǔ)齊知識(shí)短板適合作為開發(fā)過程中的案頭查詢資料。1. 一個(gè)按鍵按下去為什么要在四個(gè)模塊里繞一圈做 Airoha AB1568 藍(lán)牙耳機(jī)開發(fā)最容易翻車的不是降噪算法而是一條按鍵事件到底走了幾層才落到濾波器上。三連擊 POWER 鍵提示音響了模式也切了耳朵里卻一點(diǎn)變化都沒有——這個(gè)現(xiàn)象背后壓著三件事編譯期的宏有沒有把代碼編進(jìn)去、UI Shell 的活動(dòng)有沒有收到這條事件、NVR 里的參數(shù)有沒有真的寫進(jìn)芯片。把這三層拆開看耳機(jī)固件的黑匣子就打開了一半剩下的都是細(xì)節(jié)。2. 上電第一行代碼宏在哪個(gè) mk 文件里決定哪段代碼存在很多人調(diào)固件的第一反應(yīng)是打開工程找main然后發(fā)現(xiàn)自己改的那段代碼根本沒有被編譯。AB1568 的啟動(dòng)流程是兩段式的上電后先跑apps目錄下 bootloader 的main再由它把控制權(quán)交給apps下對(duì)應(yīng)工程earbuds或headset的main最后由apps_inits把各種應(yīng)用模塊拉起來。這條流水線上每一段都可能被條件編譯掐斷而決定掐不掐的那個(gè)開關(guān)不在.c文件里在 GCC 目錄下的某個(gè) mk 文件里。理解這件事的價(jià)值在于它把你對(duì)“代碼為什么沒生效”的排查順序從“翻代碼”改成“先確認(rèn)這段代碼是否存在于最終鏡像”。嵌入式里最貴的 bug 不是邏輯寫錯(cuò)而是邏輯壓根沒進(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ì)被編譯成真正的代碼。也就是說你把升級(jí)邏輯寫得再漂亮宏沒開那段函數(shù)體在預(yù)處理階段就被整段抹掉了鏈接器連符號(hào)都看不見。常見的實(shí)現(xiàn)思路是mk 文件里的CFG_XXX y這類寫法最終會(huì)被構(gòu)建腳本翻譯成編譯命令行的-DXXX交給預(yù)處理器。所以“宏定義在哪里”這個(gè)問題的答案永遠(yuǎn)是“在本次編譯實(shí)際引用的那個(gè) mk 文件里”而不是“在工程目錄里搜到的那個(gè)”。/* 這段代碼是否存在于固件取決于 BL_FOTA_ENABLE 是否在本次編譯的 mk 中被定義 */ #ifdef BL_FOTA_ENABLE /* 只有宏打開時(shí)這個(gè)函數(shù)體才會(huì)被編譯器看到 */ bl_fota_process(); #endif上面這段沒有參數(shù)需要解釋重點(diǎn)在語義#ifdef之外是運(yùn)行時(shí)判斷#ifdef之內(nèi)是編譯期存在性判斷。前者錯(cuò)了能在 log 里看到分支沒走后者錯(cuò)了連 log 都不會(huì)有因?yàn)槟嵌未a不存在。這也是為什么“加了打印卻沒輸出”有時(shí)候根本不是串口問題。進(jìn)到應(yīng)用層之后apps_inits統(tǒng)一初始化各應(yīng)用模塊其中就包含所有活動(dòng)行為的初始化。初始化順序在這里是有講究的誰先注冊(cè)事件組誰就能更早收到開機(jī)階段拋出的廣播事件。順序不對(duì)你會(huì)看到某些模塊在開機(jī)頭幾百毫秒里“反應(yīng)遲鈍”而幾百毫秒之后一切正?！@類現(xiàn)象很容易被當(dāng)成玄學(xué)。2.2 build.sh list宏到底落在哪個(gè) mk同一套 SDK 里通常并存多個(gè)板級(jí)工程和多個(gè)產(chǎn)品工程編譯哪個(gè)工程、用哪個(gè) mk由構(gòu)建腳本的參數(shù)決定。先列出來看清楚比在目錄里翻文件可靠得多。# 列出當(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 開發(fā)板衍生 # 對(duì)應(yīng)到 ab1568_evk 板級(jí)下的 headset_ref_desgin 工程 # 該工程編譯時(shí)引用的是 feature_68_evk 這個(gè) mk命令本身只有一句關(guān)鍵是讀輸出的方式不要只看工程名匹配要看板級(jí)前綴。ab1565_ab1568_evk是開發(fā)板名ab1568_evk是落到具體芯片型號(hào)的板級(jí)目錄產(chǎn)品工程名headset_ref_desgin只是它的一個(gè)子項(xiàng)。三者對(duì)不上你改的 mk 就不是本次編譯用的那個(gè)。確認(rèn)之后打開feature_68_evk.mk能看到現(xiàn)成的宏定義也可以往里加新的。比如 ANC 相關(guān)的MTK_ANC_ENABLE在這個(gè)文件里已經(jīng)是開啟狀態(tài)——這意味著 ANC 的按鍵處理分支是存在的問題不可能出在“沒編進(jìn)去”這一層。這個(gè)判斷很省時(shí)間一次確認(rèn)直接排除掉一整類可能性。2.3 增量編譯與 mk 變更的沖突改 mk 之后不 clean 就 build是血淚經(jīng)驗(yàn)級(jí)別的坑。構(gòu)建系統(tǒng)對(duì).c文件的依賴關(guān)系跟蹤得很細(xì)但對(duì) mk 文件的變更往往只做粗粒度判斷甚至完全依賴時(shí)間戳。結(jié)果就是宏已經(jīng)改了目標(biāo)文件卻沒重新生成你燒進(jìn)去的還是舊鏡像。# 改過任何 mk 文件之后的標(biāo)準(zhǔn)動(dòng)作 ./build.sh clean ./build.sh ab1568_evk headset_ref_desgin這兩條命令的含義很直白但順序不能省。clean清掉的是中間產(chǎn)物和最終鏡像確保下一次編譯完整展開所有 mk。省掉它的代價(jià)是幾十分鐘的迷惑你明明改了宏行為卻一點(diǎn)沒變于是開始懷疑芯片、懷疑工具鏈、懷疑人生。另外一個(gè)細(xì)節(jié)是宏的作用域。寫在 mk 里的宏是全局的寫在某個(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)聽到屬于自己事件組的才處理。這個(gè)設(shè)計(jì)看著低效實(shí)際上解決了嵌入式 UI 里最麻煩的問題狀態(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è)棧決定了“誰在前臺(tái)”。app_preproc_activity_proc是主進(jìn)程負(fù)責(zé)管理和調(diào)配其它子進(jìn)程比如app_home_screen_idle_activity_proc這類具體界面。開機(jī)后系統(tǒng)會(huì)拉起很多不同的進(jìn)程每個(gè)進(jìn)程里有不同的事件組形成一張扁平的監(jiān)聽網(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 }, /* 按鍵類事件 */ { ANC_EVENT_GROUP, app_home_screen_proc_anc_event_group }, /* ANC 狀態(tài)變化 */ { TIMER_EVENT_GROUP, app_home_screen_proc_timeout_event }, /* 超時(shí)類事件 */ }; /* 啟動(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)用的語義是先聲明“我關(guān)心哪幾類事件、分別交給誰處理”再聲明“我現(xiàn)在進(jìn)入活動(dòng)?！?。第三個(gè)參數(shù)是處理表長度最后一個(gè)布爾量在不同 SDK 版本里可能是“是否獨(dú)占前臺(tái)”之類的開關(guān)入?yún)㈨樞蛞渤Ｓ姓{(diào)整理解成“注冊(cè)范圍 前臺(tái)聲明”這兩件事就夠了。真正要記住的是處理表在注冊(cè)時(shí)就被固定下來活動(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ì)列里的事件取出來分派給活動(dòng)ui_shell_remove_event則是后悔藥——把還沒被消費(fèi)的事件從隊(duì)列里摘掉。/* 投遞一條按鍵事件不來自中斷、優(yōu)先級(jí)普通、屬于按鍵事件組 */ ui_shell_send_event(false, /* 是否來自中斷上下文 */ EVENT_PRIORITY_NORMAL, KEY_EVENT_GROUP, /* 事件組決定誰來處理 */ KEY_EVENT_ANC_SWITCH, /* 事件 ID具體是什么事 */ payload, /* 附帶數(shù)據(jù)可為 NULL */ sizeof(payload), NULL, 0); /* 后悔藥場景已經(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é)作的工程里非常常見也是事件丟了的經(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ì)不屬于自己的事件做一次快速丟棄而且“誰在前臺(tái)誰處理”這條隱含規(guī)則沒有被框架強(qiáng)制。當(dāng)兩個(gè)活動(dòng)同時(shí)存在于棧上、又都注冊(cè)了同一個(gè)事件組就會(huì)出現(xiàn)同一條按鍵被處理兩次的現(xiàn)象——比如降噪模式連跳兩格。ui_shell_remove_event的存在就是為了補(bǔ)這個(gè)洞在狀態(tài)切換的瞬間把上一條還沒被消費(fèi)完的事件摘掉避免它在新的上下文里被執(zhí)行。我一般會(huì)這么理解這套框架廣播負(fù)責(zé)“送達(dá)”活動(dòng)棧負(fù)責(zé)“當(dāng)前誰該管”remove負(fù)責(zé)“別管過期的”。三者缺一個(gè)行為就會(huì)在某些邊角場景里歪掉。判斷一條事件有沒有人處理最直接的辦法是在ui_shell_init_input_msg的分派路徑上加一行 log打印事件組和事件 ID。有投遞記錄但沒有處理記錄說明當(dāng)前棧上沒有活動(dòng)注冊(cè)該事件組兩者都有但業(yè)務(wù)沒反應(yīng)問題就在處理函數(shù)內(nèi)部跟框架無關(guān)。這條分界線劃清楚排查效率會(huì)差好幾倍。4. ANC 模式切換從 key_action 到 ANC 濾波器組ANC 是耳機(jī)固件里鏈路最長的一個(gè)功能它橫跨按鍵、事件框架、服務(wù)層和聲學(xué)參數(shù)四層。任何一層斷掉用戶聽到的都是“沒效果”但從代碼上看每一層都“跑過了”。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é)說話拾音配 2 個(gè)振動(dòng)喇叭和 2 個(gè)聲音喇叭。分工很清楚ANC 降噪用 FF 和 FB通話降噪用 talk 麥加 FF。config tool 上有三個(gè)參數(shù)頁ANC含 FF 與 FB、FBC、Passthrough通透。它們和用戶感知的“模式”不是一一對(duì)應(yīng)關(guān)系模式是給用戶按的參數(shù)頁是給聲學(xué)工程師調(diào)的。一個(gè) ANC 模式背后會(huì)同時(shí)用到 ANC 頁和 FBC 頁的參數(shù)通透模式背后是 Passthrough 頁的參數(shù)。把這層關(guān)系理順才看得懂后面濾波器編號(hào)的分配邏輯。4.2 key_action 的四種語義與映射文件按鍵事件進(jìn)來后先進(jìn)_proc_key_event_group處理。這條路徑能不能走通前提是MTK_ANC_ENABLE已經(jīng)打開——在feature_68_evk.mk里確認(rèn)過是開的。所有 ANC 相關(guān)行為最終都收斂到app_home_screen_process_anc_and_pass_through這一個(gè)函數(shù)里靠key_action的值區(qū)分意圖。/* key_action 的四種語義對(duì)應(yīng) config tool 里配置的按鍵行為 */ switch (key_action) { case KEY_ANC: /* 單純 ANC 開 / 關(guān)不碰通透 */ target_anc_type (target_anc_type ANC_OFF) ? ANC_ON : ANC_OFF; break; case KEY_PASS_THROUGH: /* 單純通透開 / 關(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: /* 兩段來回只在通透和 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ò)語義用戶按三下會(huì)回到原點(diǎn)或者卡在通透出不來——這類“手感問題”最后都會(huì)被當(dāng)成 bug 報(bào)上來。按鍵行為和key_action的綁定寫在customerized_key_config.c里。這個(gè)文件是產(chǎn)品差異化的集中地不同客戶的長按、雙擊、三連擊語義都在這里分叉。改這里之前先確認(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ù)字不是隨手寫的它們對(duì)應(yīng) NVR 里參數(shù)塊的編號(hào)。NVR 里的濾波器按四組組織每組包含左右耳各一套組內(nèi)容說明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ì)稱性就出來了。切換 ANC 模式時(shí)看 loganc_result里三個(gè)模式循環(huán)出現(xiàn)每次都會(huì)帶上當(dāng)前使用的 filter id。這個(gè)字段是排查“切了但沒效果”的第一手證據(jù)id 變了說明鏈路通到了服務(wù)層沒變說明卡在按鍵或狀態(tài)機(jī)。4.4 NVR 參數(shù)從 config tool 到芯片的那一段三連擊 POWER有提示音沒有降噪效果——這是最典型的一類現(xiàn)象。原因往往極其樸素用 config tool 打開工程的download目錄ANC 模式下的參數(shù)是空的。代碼路徑全對(duì)參數(shù)沒寫DSP 拿到的是一組零。修復(fù)流程是把聲學(xué)調(diào)好的 ANC 參數(shù)nvr 文件導(dǎo)入工程或者直接在 tool 上調(diào)整然后先 Write NV 再 Reset把 FF、FB、FBC 和 AiroThru 參數(shù)寫進(jìn)耳機(jī)。之后循環(huán)三連擊能聽出不同模式的降噪差異才算真正打通。參數(shù)寫進(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 位超過 0x7FFF 說明是負(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ú)寫成腳本的原因很實(shí)際調(diào)音階段你會(huì)反復(fù)對(duì)比“tool 里顯示的”和“芯片里存的”是否一致。手算一次兩次還行改十幾次參數(shù)之后必然出錯(cuò)而錯(cuò)的方向還挺隱蔽——正負(fù)號(hào)搞反降噪曲線就整條翻過來。5. 排查清單ANC 沒效果、宏不生效、參數(shù)回滾的五個(gè)常見坑這一章的五條記錄都來自實(shí)際調(diào)試現(xiàn)場共同點(diǎn)是代碼看起來沒問題現(xiàn)象卻穩(wěn)定復(fù)現(xiàn)。每條按現(xiàn)象、原因、解決三段寫方便對(duì)號(hào)入座。5.1 有提示音、沒降噪?yún)?shù)沒寫進(jìn)芯片現(xiàn)象三連擊 POWER 鍵提示音響了log 里anc_result也在三個(gè)模式之間循環(huán)但左右耳聽感完全沒變化。原因用 config tool 打開工程download目錄ANC 模式下沒有參數(shù)。代碼路徑通了服務(wù)層也執(zhí)行了但下發(fā)給 DSP 的是一組全零系數(shù)。降噪算法在零系數(shù)下等價(jià)于直通所以“切了等于沒切”。解決導(dǎo)入聲學(xué)調(diào)好的 nvr 文件或者直接在 tool 上調(diào)整 ANC、FBC、Passthrough 三頁參數(shù)然后 Write NV再 Reset。重置這一步不能省部分參數(shù)在初始化階段才被讀取不 Reset 就只能等下次上電。驗(yàn)證方式是循環(huán)三連擊聽感上能區(qū)分出不同模式的降噪強(qiáng)度差異。5.2 改了宏沒生效改的不是本次編譯的 mk現(xiàn)象在某個(gè) mk 文件里加了宏定義重新編譯燒錄行為毫無變化或者鏈接時(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ò)都沒有。5.3 參數(shù)回滾只改了 download沒改 XML 和 bin現(xiàn)象參數(shù)在 tool 里調(diào)好了也 Write NV 驗(yàn)證過效果。重新編譯工程、燒錄之后ANC 又回到舊參數(shù)。原因Write NV 寫的是耳機(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里不一定有沒有的要新增已有的要替換比如 ANC 參數(shù)涉及的0xEE00~0xEEFF段在nvkey.xml里就沒有。同時(shí)替換filesystem.bin再 clean build。5.4 按鍵無響應(yīng)事件發(fā)出去了沒人接現(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 的處理表根本沒參與分派。另一種情況是事件組 ID 用錯(cuò)發(fā)到了另一個(gè)組名下。解決在ui_shell_init_input_msg的分派路徑上打一行 log同時(shí)打印事件組和事件 ID對(duì)比活動(dòng)注冊(cè)表里的事件組。有投遞無分派就是路由問題有分派無業(yè)務(wù)響應(yīng)才是處理函數(shù)的問題。另外在狀態(tài)切換的地方補(bǔ)ui_shell_remove_event把過期事件摘掉避免它在新上下文里被誤執(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ù)卻沒走換算宏或者在改 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í)就是單位問題差幾秒就是 tick 精度問題。自動(dòng)關(guān)機(jī)還涉及關(guān)機(jī)前的提示音和 LED 狀態(tài)收尾時(shí)間設(shè)置過短會(huì)在提示音播到一半時(shí)斷電聽感上像是“關(guān)機(jī)有雜音”。6. 參數(shù)固化還是 FOTA 下發(fā)NVKEY 的兩條路怎么選ANC 參數(shù)最終要落到耳機(jī)里有兩條路編譯進(jìn)固件或者通過 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ù)聽一次效果不用等編譯。定版之后必須固化到 XML 和filesystem.bin讓產(chǎn)線拿到的每一臺(tái)耳機(jī)參數(shù)完全一致——參數(shù)固化到代碼里的價(jià)值不是“省事”而是“可復(fù)現(xiàn)”。驗(yàn)證是否真的固化了方法很樸素clean build 生成新的download用 config tool 打開看 ANC 參數(shù)是不是剛才導(dǎo)入的那一版如果不是說明 XML 沒更新全或者filesystem.bin沒替換。再狠一點(diǎn)的驗(yàn)證是把耳機(jī)擦除后重新燒錄讀回 NV key 跟預(yù)期值逐字節(jié)比對(duì)比肉耳聽降噪靠譜得多。踩過一次坑之后我就養(yǎng)成了習(xí)慣每次改 NV 參數(shù)先問自己一句“這是要驗(yàn)證還是要定版”驗(yàn)證走 Write NV定版走 Special_Export XML/bin 替換兩條路絕不混用。混用的后果是某天發(fā)現(xiàn)倉庫里的參數(shù)和產(chǎn)線耳機(jī)對(duì)不上而沒人記得是哪次改的。從那以后我每次動(dòng) NV key 都強(qiáng)制走一遍“導(dǎo)出、更新 XML、替換 bin、clean build、tool 復(fù)核”這五步一步不跳。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取