企业官网建设流程全解析

简介：这份PDF资料面向从事Airoha洛达AB1568蓝牙耳机固件与应用开发的工程师，系统梳理该芯片平台从底层启动到上层功能实现的开发要点，适合具备一定嵌入式与蓝牙协议基础、希望快速上手或查漏补缺的中级开发者。压缩包内为1个PDF文件，约9.58MB，内容以工程分析为主线，涵盖上电后执行函数、mk文件中的宏定义、app活动行为开启、ANC模式切换、LED呼吸灯样式修改、充电参数监测、超时时间与事件收发删除、Airoha API参考、回调注册调用、自动关机与配对时间配置、开机提示电量、清除配对列表、链路丢失重连、UI Shell框架、SideTone与音频路径设置、DUT模式测RF、硬件复位及PEQ设定等模块，目录结构清晰，便于按主题检索。已有374人学习，可作为开发过程中的查阅手册与功能实现参考。

1. 拿到 AB1568 headset 工程后，先搞清楚它到底能干什么

如果你手上有一份 Airoha AB1568 蓝牙耳机的 headset 工程源码，打开后看到一堆apps、mk、activity、nvkey目录，第一反应大概率是懵的。这份工程分析资料的价值就在于：它把从 bootloader 上电到 ANC 切换、从宏定义位置到 FOTA 更新 NVkey 的整条链路拆成了三十多个可查的点。它不是一份 API 手册，而是一份“照着做就能跑通”的工程笔记。适合谁？适合已经拿到 AB1568 开发板或头戴耳机样机、需要做 ANC 调试、按键行为定制、产测模式配置的嵌入式蓝牙开发人员。新手可以按章节顺序跟，熟手可以直接跳到 ANC 参数固化或 NVkey 解析那几节。下面我按“工程怎么跑起来 → 功能怎么改 → 坑在哪”的顺序，把这份资料里真正能落地的部分拆开讲。

2. 从 bootloader 到 activity：工程启动链路与宏定义定位

2.1 上电后到底先跑哪个 main

AB1568 的启动不是一上来就进你的应用代码。上电后先执行的是apps目录下 bootloader 的main函数，这里有一个条件编译的坑：BL_FOTA_ENABLE这个宏必须在 GCC 目录下的 mk 文件里定义，bl_fota_process函数才会被编译进去。也就是说，如果你发现 FOTA 相关代码“写了但没生效”，先别怀疑逻辑，去查这个宏有没有开。

bootloader 跑完后才跳到apps下对应工程（earbuds或headset）的main函数，接着apps_inits函数初始化各种应用模块。这个顺序意味着：你在应用层加的初始化代码，一定是在 bootloader 完成之后才执行的。如果某个外设在 bootloader 阶段就被配置过，应用层再配一次可能会冲突，这是排查外设异常时第一个要看的地方。

2.2 宏定义在哪个 mk 文件里，别靠猜

工程里 GCC 目录下有一堆 mk 文件，宏到底定义在哪个文件里，取决于你编译的是哪个工程。资料里给了一个很实用的办法：先用命令列出编译不同工程时调用的 mk 文件。

# 在工程根目录执行，列出各工程对应的 mk 文件 ./build.sh list

执行后能看到类似ab1568_evk的headset_ref_desgin工程调用的是feature_68_evk文件。打开这个文件，里面就是当前工程生效的宏定义集合。你要加新宏，也加在这里。这里有个血泪经验：不要直接在代码里#define一个和 mk 文件里同名的宏，编译器会给你 warning，但很多人忽略后调试半天，最后发现是两处定义打架。常见做法是统一在feature_68_evk.mk里管理，代码里只做#ifdef判断。

2.3 activity 堆和事件分发：UI Shell 的骨架

apps_inits里包含了所有活动行为的初始化。ui_shell_start_activity函数的作用是给一个活动在活动堆里申请空闲 item。app_preproc_activity_proc是主进程，负责管理和调配其它子进程，比如app_home_screen_idle_activity_proc。开机后系统会开启很多不同的进程，每个进程里有不同的事件组。系统产生一个事件时会把事件抛出去，所有进程都能监听到，但只有事件属于自己的那个进程才会处理。

这套机制类似一个个 UI 界面：你处于某个 activity 时，发生的事件就由这个 activity 处理。比如在 home_screen 状态下，能处理的事件是有限集合。理解这一点很关键——你加了一个按键事件但没反应，很可能不是按键没配好，而是当前 activity 根本没监听这个事件组。排查时先确认当前 activity 的 event group 里有没有你的事件 ID。

3. ANC 模式切换：从按键行为到滤波器参数落地

3.1 音频通路与四种 ANC 模式的对应关系

AB1568 的音频通路分 Line-in 和 BT 两种。ANC 用 FF 麦（前馈）和 FB 麦（反馈）实现，Configtool 上有三种参数：ANC、FBC、Passthrough，其中 ANC 包含 FF 和 FB，FBC 是 FB 的补偿。硬件上 4 个麦克风用于降噪，1 个主麦负责说话，2 个振动喇叭加 2 个声音喇叭。音频降噪用 FF 和 FB，通话降噪用 talk 麦和 FF。

目标是：在 home_screen 状态下用按键切换 ANC 模式。按键事件进入_proc_key_event_group处理，这里需要MTK_ANC_ENABLE宏开启，去feature_68_evk.mk确认已开。所有 ANC 事件行为都调用app_home_screen_process_anc_and_pass_through函数处理。按键行为key_action有四个值：

按键行为到key_action的映射在customerized_key_config.c文件里配。这里对应 Configtool 的 UI 行为，改完要重新编译才生效。

3.2 三连击有提示音但没降噪效果，问题出在参数没写进去

资料里记录了一个非常典型的翻车现场：配好三连击 POWER 键，有提示音，但 ANC 没效果。原因是用 Configtool 打开工程的download文件夹，发现 ANC 模式里根本没有调整过的参数。也就是说，按键逻辑通了，但滤波器参数是空的。

解决路径是：把声学调好的 ANC 参数（nvr 文件）通过 Configtool 的 Import NVR 功能导入工程，或者直接在 tool 上调整。然后先 Write NV 再 Reset，把 FF、FB、FBC 和 AiroThru 参数写入耳机。写完后再循环三连击，能听出不同 ANC 模式的降噪差异，才算真正使能成功。

ANC 执行代码的逻辑是：KEY_SWITCH_ANC_AND_PASSTHROUGH改变变量target_anc_type和target_filter_id的值，再传入app_anc_service_enable函数执行。看切换时的 log，过滤anc_result能看到三个模式循环切换。ANC 默认滤波器AUDIO_ANC_CONTROL_ANC_FILTER_DEFAULT是值为 1 的枚举，PassThrough 默认滤波器AUDIO_ANC_CONTROL_PASS_THRU_FILTER_DEFAULT是值为 9 的枚举。

3.3 把 ANC 参数固化到代码：Special_Export 与 nvkey.xml 的对应

参数调好后只存在 download 文件里，换台机器编译就丢了。要固化到代码，流程是这样的：先 clean 再 build 生成最新 download 文件，然后用 Configtool 打开 download，导入声学 NVR 文件，再用 Special_Export 导出变更。导出会生成 4 个文件，如果用 Save 方式保存成 download 文件则生成 3 个文件，其中 syskey 和 bin 文件是一致的。有一部分 NVkey 被保存到filesystem.bin里。

XML 和 bin 文件用在量产程序编译。编译工程代码时用多个 XML 文件一起编译生成 bin 文件，以ab1568_evk为例：xml 1 有 7 个 KeyID，xml 2 有 4 个 KeyID，xml 3 有剩下的所有 KeyID。把 Special_Export 导出的syskey.xml里变更的参数一一更新到这三个nvkey.xml文件即可。注意一个细节：syskey.xml里有的 keyID，在nvkey.xml里不一定有，没有的就添加，有的就替换。ANC 参数的 keyID 在0xEE00~0xEEFF范围，这些在nvkey.xml里原本没有，需要手动补。同时替换filesystem.bin文件，重新编译生成 download，用 Configtool 打开确认 ANC 参数变成了 nvr 文件的配置，才算固化成功。

3.4 Component Gain 的 NVR 解析：高低字节反转别搞错

ANC Default Setting 里有个 Component Gain 校准，NVR 解析容易翻车。比如0xE1E5 = 10FF 1400 D8DC D8DC，高字节在前低字节在后。FF(10FF)对应 -2.4dB（component gain 是 -240），解析时要把前后位反转：10FF → FF10，十六进制转十进制再减去 65536 得到正确值。FB(1400)对应 0.2dB（component gain 是 20），反转1400 → 0014，十六进制转十进制直接得到正确值。正负值的处理方式不同，这一步搞反了增益就全错，降噪效果自然不对。

4. 事件、超时与电源管理：那些容易配漏的细节

4.1 ui_shell_send_event 与 remove_event 的配对使用

ui_shell_send_event是发送事件的核心函数，ui_shell_remove_event用来删除事件，ui_shell_init_input_msg负责接收事件消息。这三个函数构成事件管理的闭环。常见误用是只 send 不 remove，导致事件队列里堆积过期事件，表现为某个功能“偶尔触发两次”或者“延迟响应”。我一般会在 activity 退出时统一清理该 activity 注册的事件，而不是依赖超时自动回收。

超时时间设置和自动关机配置是节能管理的一部分。自动关机配置在资料里有专门一节，配对时间设置则影响用户连接体验。开机提示电量功能需要和电量监测机制整合，读取电池电压电流后判断是否播报。这些配置项分散在不同文件里，改的时候建议列一个清单逐项确认，别改了一个忘了另一个。

4.2 清除配对列表与链路丢失重连

清除配对列表用于隐私保护和重新配网场景，链路丢失重连则决定耳机断连后的行为。这两个功能在代码里是独立的模块，但实际使用中会互相影响：清除配对列表后如果重连逻辑还在跑，可能会出现反复尝试连接已清除设备的情况。排查时先看清除操作有没有正确通知到重连模块。

4.3 SideTone、PEQ 与通话降噪的配置边界

SideTone 设置影响通话时自己听到自己声音的量，PEQ 设定方法用于音效调校，通话降噪及 iGO 算法、ENC 通话降噪是通话场景的降噪链路。这几项和 ANC 是不同链路：ANC 管听音降噪，ENC 管通话降噪，别把参数配串了。音频路径设置决定了 Line-in 和 BT 通路的走向，改之前先画清楚信号流，否则调半天发现改的是另一条路。

5. 避坑与排查：五个真实踩过的坑

5.1 FOTA 代码不生效

现象：写了 FOTA 相关逻辑，编译通过但运行没反应。原因：BL_FOTA_ENABLE宏没在 GCC 目录的 mk 文件里定义，bl_fota_process根本没被编译进去。解决：去feature_68_evk.mk确认宏已开，clean 后重新 build。

5.2 ANC 按键有提示音无降噪

现象：三连击有提示音，但听不出降噪差异。原因：ANC 滤波器参数没写入，download 文件里 ANC 模式参数为空。解决：Import NVR 导入声学参数，Write NV 后 Reset，确认 log 里anc_result有模式切换记录。

5.3 宏定义冲突导致行为异常

现象：某功能时好时坏，或者编译有 warning 但被忽略。原因：代码里#define了和 mk 文件同名的宏，两处定义不一致。解决：统一在 mk 文件管理宏，代码里只做条件判断，编译时留意 warning。

5.4 NVkey 固化后参数没变

现象：按流程改了nvkey.xml和filesystem.bin，重新编译后 ANC 参数还是旧的。原因：syskey.xml里的 keyID 在nvkey.xml里不存在时没手动添加，或者filesystem.bin没同步替换。解决：逐项核对 keyID，0xEE00~0xEEFF范围的要手动补进nvkey.xml，bin 文件一起替换。

5.5 Component Gain 解析出错误增益值

现象：降噪效果和预期差很多，增益明显不对。原因：NVR 高低字节反转后正负值处理方式搞混，负值忘了减 65536。解决：负值反转后减 65536，正值反转后直接转十进制，用资料里的0xE1E5例子对照验证。

6. 进阶验证：用 DUT 模式和 AT 命令把改动锁死

改完 ANC 和 NVkey 后，怎么确认真的生效而不是“听起来差不多”？资料里给了两条验证路径。第一条是 DUT 模式测 RF，配合产测测试模式做射频指标确认。第二条是 AT+CMD 命令和 RACE/RAW 指令，通过 USB 口通信打 log，直接看寄存器值和 NVkey 读取结果。

读取耳机现有 NVkey 是验证固化的关键一步。改完参数后，用 AT 转 Race 指令格式发读取命令，对比返回值和你写入的值是否一致。这里有个习惯我一直在用：每次改完 NVkey，先不急着听效果，先用读取命令把关键 keyID 的值拉出来对一遍，确认写入成功再去做主观听感测试。因为听感受环境影响大，玄学成分不少，但寄存器值不会骗人。

设置设备信息和 SDK 的 NVKEY 管理也在这条链路上。设备信息写错会导致配对名异常，NVKEY 读写权限配错会导致参数“写了但读不到”。AP 测试和硬件复位功能则是产测阶段的收尾项，硬件复位要确认复位后 NVkey 不丢失，否则量产时会出现“复位一次参数回默认”的问题。

从那以后我每次改完 ANC 参数，都强制走一遍“Special_Export → 更新 nvkey.xml → 替换 filesystem.bin → clean build → 读取 NVkey 比对 → 主观听感”的完整流程，少一步都可能留下后悔药。希望这份拆解帮到你，少走几个我走过的弯路。

本文还有配套的精品资源，点击获取