基于炬芯ATS308X的Find my防丢器查找器功能实现

# ATS3089P 设备查找与防丢报警本功能用于手机 BLE App 查找附近开发板以及 BLE 连接丢失后的本机声音报警。PC 直接使用原有普通 UART 串口发送指令。这里的“Find My”是本地 BLE 查找功能没有接入 Apple 查找网络。查找声音由固件实时合成无需向 U 盘复制 MP3、WAV 或 PCM 文件。防丢默认关闭开启状态保存到 NVRAM断电重启后保留每次开机仍须先连接手机才开始监护该手机的 BLE 连接。## 1. PC 串口直接查找使用当前能看到 uart:~$ 提示符的普通 UART 串口沿用原串口参数按文本发送指令后加回车即可。不需要开启 USB CDC 或切换 USB 模式。textapp findmy startapp findmy statusapp findmy stop| 指令 | 作用 || --- | --- || app findmy start | 播放查找声音默认 30 秒 || app findmy start 10 | 播放 10 秒可指定 1300 秒 || app findmy stop | 停止当前查找、防丢报警或断连确认等待 || app findmy status | 查看连接、布防、播放和错误状态 || app findmy anti_loss on | 开启防丢并保存当前已连接的手机作为监护对象 || app findmy anti_loss off | 关闭防丢并保存取消断连确认等待和防丢报警 |手动查找不要求 BLE 已连接PC 可以独立验证声音。重复发送 start 会重新计算本次查找的结束时间。stop 只结束当前报警不修改保存的防丢开关若要长期关闭使用 anti_loss off。查找或防丢报警期间单击开发板 **K2** 也可以停止声音包括取消尚未结束的 5 秒确认等待。没有查找或防丢任务时K2 继续原有的内置铃声切歌操作。## 2. 手机 BLE App 查找沿用 [BLE_RECORD_CONTROL.md](BLE_RECORD_CONTROL.md) 的服务、特征、通知订阅和四字节 CRC-8 格式。录音原来的 0003 控制值不变查找使用 10/11防丢使用 20/21均为十六进制。使用通用 BLE 调试 App 时1. 扫描并连接开发板的 BLE 设备发现 GATT 服务。2. 找到服务 7b2e1000-8e7f-4d3a-9c61-2a3089c00001 和特征 7b2e1001-8e7f-4d3a-9c61-2a3089c00001。3. 开启该特征 NotifyCCC 写入 01 00选择 HEX 输入。4. 向该特征写入 AA 01 11 AD开发板开始播放 30 秒查找声音写入 AA 01 10 AA 停止。帧格式为 AA SET/GET 控制字段 CRC800GET01SET。CRC 参数与原录音协议完全相同多项式 07、初值 00计算前 3 字节。| 操作 | 发送 HEX 字节 | 固件行为 || --- | --- | --- || 开始查找 | AA 01 11 AD | 播放 30 秒查找声音 || 停止声音 | AA 01 10 AA | 停止当前查找、防丢报警或确认等待 || 查询查找状态 | AA 00 10 BF | 通知当前查找状态 || 开启防丢 | AA 01 21 3D | 保存开启状态监护发送指令的手机 || 关闭防丢 | AA 01 20 3A | 保存关闭状态取消防丢任务 || 查询防丢状态 | AA 00 20 2F | 通知当前防丢与布防状态 |通知同样为 4 字节SET/GET 字节沿用请求控制字段表示执行后的状态CRC 重新计算| 通知控制字段 | 含义 || --- | --- || 10 / 11 / 12 / 13 | 空闲 / 查找中 / 防丢报警窗口 / 断连确认等待 || 20 / 21 / 22 / 23 | 防丢关闭 / 已开尚未布防 / 已布防且已连接 / 已布防且已断连 || 81 / 82 / 83 | 音频忙 / 执行或保存失败 / 请求来源连接已失效 |App 应发送二进制 HEX 字节不发送 ASCII 字符串。每次只写一帧 4 字节长度、offset、操作、控制值和 CRC 均会校验。BLE 回调只接收并排队应用线程处理后通知结果。请等通知后再发送下一条查询查找和防丢使用上表 GET 帧直接 Read 仍返回原有录音状态。开关保存到 NVRAManti_loss on 和 BLE 开启均使用等级 02。原先的标准 IAS 1802/2A06 和 LLS 1803/2A06 单字节入口仍兼容当前 App 对接统一使用上表四字节指令即可。## 3. 防丢使用流程建议先将手机和开发板放在一起保持 App 的 BLE 连接再开启防丢textapp findmy anti_loss onapp findmy status或由手机向原录音控制特征写入 **AA 01 21 3D**。状态应显示 anti_loss2 connected1 armed1。随后保持 App 连接逐渐远离开发板。当蓝牙控制器报告连接超时 0x08 或 LL 响应超时 0x22 时固件进入 **5 秒确认等待**。等待期间同一监护手机恢复连接会取消报警5 秒后仍未连接则进入 **60 秒防丢报警窗口**。textfindmy: LINK_LOSS reason0x08 confirm in 5sfindmy: ANTI_LOSS alarm 60sfindmy: tone started 2500/3200 Hz, 16 kHz mono5 秒从**固件收到超时断连事件**开始计算。蓝牙自身还有连接监督超时所以从实际走远到发声通常会更久不能理解为离开范围后立即开始 5 秒倒计时。以下操作可以结束防丢报警或确认等待- 同一监护手机重新连接 BLE。- PC 执行 app findmy stop或手机发送 AA 01 10 AA。- 开发板单击 K2。- 执行 app findmy anti_loss off或手机发送 AA 01 20 3A。- 60 秒报警窗口结束。停止一次报警后防丢开关仍可保持开启手机再次连接后后续超时断连仍会触发新的监护流程。若需要换一部手机在新手机已连接 BLE 时重新执行 anti_loss on或发送 AA 01 21 3D监护对象改为当前手机。主动断连 0x13对端主动断开和 0x16本机主动断开不触发防丢。断电重启时即使已保存开启状态尚未连接过手机也不会报警以免手机不在身边时开机误响。防丢依赖 **App 持续保持 BLE 连接**手机系统应允许 App 在后台运行。只在手机系统中连接传统蓝牙音乐或 HFP 通话不代表 App 的 BLE 连接仍存在。App 被系统结束、手机关机或信号被遮挡也可能出现超时断连不能单凭报警判断一定是距离变远。本功能按连接丢失报警没有把 RSSI 换算为米数。## 4. 声音、音频优先级与状态固件以 16 kHz、16 bit、单声道 PCM 实时合成以下节奏并循环text2500 Hz 120 ms → 静音 100 ms → 2500 Hz 120 ms → 静音 100 ms→ 3200 Hz 240 ms → 静音 800 ms → 重复声音经过开发板现有 DAC 和扬声器输出不需要单独蜂鸣器。短音首尾做幅度渐变减少突然开始和停止时的爆音。报警期间使用 PARTIAL 唤醒锁保持 CPU 和音频运行不要求屏幕常亮。通话和其他音频优先正在通话、播放 MP3、PCM 或其他占用音轨的音频时手动查找返回 -EBUSY通常为 -16不会强行停掉它们。允许查找接管原有内置铃声。防丢触发时若音频忙碌会在剩余 60 秒窗口内等待音轨可用窗口不会因为等待而延长。查找报警已经播放后其他播放器新建音轨会结束本次报警并释放资源让原功能正常播放。app findmy status 示例textfindmy: version261014-v2 ret0 anti_loss2 connected1 armed1 pending0 source0 playing0 remaining0s reason0x00 error0| 字段 | 含义 || --- | --- || version | 本次功能版本 261014-v2用于核对实际烧录版本 || ret | 本次 shell 操作结果0 成功如 -16 表示音频忙碌 || anti_loss | 保存的防丢等级0 关闭1/2 开启 || connected | 监护手机当前是否 BLE 已连接 || armed | 本次开机是否已连接手机并进入防丢监护 || pending | 是否正在等待超时断连后的 5 秒确认 || source | 0 空闲1 手动/手机查找2 防丢报警窗口 || playing | 查找声音线程当前是否正在执行播放任务 || remaining | 确认等待或本次报警窗口的剩余秒数 || reason | 最近监护手机的断连原因0x08/0x22 可触发防丢 || error | 核心或声音播放最近的错误码0 无错误 |播放在后台启动刚执行 start 时可能先看到 source1 playing0稍后查看应进入播放。source2 playing0 也可能表示防丢窗口正在等待其他音频释放。## 5. 代码入口与流程| 文件 | 作用 || --- | --- || src/main/findmy.c / findmy.h | 查找时长、监护手机、5 秒确认、60 秒窗口、状态和 NVRAM 设置 || src/main/ble_record_protocol.h / ble_record_service.c | 原四字节协议、查找/防丢扩展、统一排队和通知 || src/main/findmy_service.c / findmy_service.h | 查找/防丢 BLE 执行、连接事件及标准服务兼容入口 || src/main/findmy_tone.c / findmy_tone.h | 后台声音线程、PCM 合成、音轨清理与唤醒锁 || src/main/system_app_shell.c | app findmy 串口指令入口 || src/main/system_app_main.c | 蓝牙就绪后注册服务处理 BLE 查找消息 || src/main/ringtone_play.c | K2 单击停止查找、防丢报警 || framework/audio/audio_track.c | 新音轨建立前调用准备钩子让其他播放器优先并释放报警音轨 |功能开关为 CONFIG_APP_FINDMYATS3089P 的 prj.conf 启用该配置。防丢等级通过属性 FINDMY_LEVEL 保存监护对象和当次报警时间为本次运行状态不保存到 NVRAM。立即查找流程BLE 四字节写入或串口 start → 校验及应用处理 → 设置时长 → 后台声音线程 → 到时、指令或 K2 停止 → 关闭音轨并释放唤醒锁。防丢流程启用并保存 → 连接手机后布防 → 过滤真实 BLE 超时断连 → 确认 5 秒 → 进入 60 秒窗口 → 音频可用时发声 → 重连、停止或到时清理。## 6. 上板验证与固件建议依次验证1. PC 执行 start 5听到“滴滴哒”循环并约 5 秒后停止执行 start 后单击 K2确认停止。2. 手机连接 BLE订阅原录音特征 Notify发送 AA 01 11 AD 开始查找、AA 01 10 AA 停止。3. 发送 AA 01 21 3D 开启防丢再发送 AA 00 20 2F 查询串口确认 connected1 armed1。4. 保持 App 后台 BLE 连接远离直至日志出现 LINK_LOSS确认约 5 秒后报警。5. 确认等待内重新连回、报警中重新连回都应停止主动在 App 断开连接应打印 no alarm。6. 断电重启确认 anti_loss 仍开启而手机未连接前 armed0、不会误响。7. 通话或其他音乐播放期间发起查找应返回忙碌报警中开始其他音频应结束报警原播放和多次通话继续正常。2026-10-14 已完成 ATS3089P 开发板固件编译与打包烧录包如下路径相对于 application/bt_watchtextoutdir/ats3089p_dev_watch/_firmware/ats3089p_dev_watch_261014_findmy_v2.fwoutdir/ats3089p_dev_watch/_firmware/ats3089p_dev_watch_261014_findmy_v2_debug.fw软件验证已通过Find My 状态与 BLE 四字节指令共 66,393 项断言包括原录音指令兼容性、完整操作/控制值校验以及真实 ARM ELF 的声音频率、节奏、短写、停止取消、音轨清理和抢占测试。原有 BLE 录音、HFP 多次通话路由、K2 铃声及 MP3 播放器回归也通过。在 SDK 根目录可运行以下脚本复查详细依赖见 tests/findmy/README.mdtextpython application/bt_watch/tests/findmy/run_tests.pypython application/bt_watch/tests/findmy/run_tone_tests.py --wav application/bt_watch/outdir/findmy_tests/preview.wavpython application/bt_watch/tests/findmy/run_shell_tests.py声音测试生成 outdir/findmy_tests/preview.wav可在电脑试听三轮“滴滴哒”。扬声器实际响度、手机 App 后台连接和远离后的报警仍需按上述步骤上板确认。## 7. 烧录后核对版本与串口入口本次新包文件名带 findmy_v2烧录后重新启动在原普通 UART 执行textapp findmy statusapp findmy start 5状态首行应包含 findmy: version261014-v2蓝牙就绪后会打印Find My v2 261014 UART / BLE AA control ready。当前真实 ELF 已执行 Shell 根命令、子命令查找和处理函数测试合法 app findmy不会进入 app unknown parameter还逐字节核对了 ELF 导出的 zephyr.bin 和打包app.bin 中的命令表及代码。若板上仍返回 unknown parameter: findmy说明运行中的命令表与该构建不一致需要核对烧录工具选择的完整文件名、烧录是否成功和冷启动版本。单凭运行中日志无法确认板上实际固件。