CH582M 低功耗 + BLE 唤醒坑【初稿】¶

本文记录一次真实调试中暴露出的 「睡眠 + BLE」固件陷阱：芯片能烧录、官方 HID 例程能搜到（弱）信号，但自己的「睡眠 + BLE」固件完全搜不到蓝牙。结论先放：硬件射频链路是活的，完全静默几乎是固件侧「睡眠唤醒没把射频重新拉起来」导致，不是板子死。本文是基于调试推理的初稿——具体的 WCH API 名称（如低功耗入口、TMOS 调度）以官方 BLE 例程 / datasheet 为准，待固件实测后补全。

一、现象回顾¶

同一份「睡眠 + BLE」固件：

板子 / 固件	结果
淘宝开发板（同固件）	✅ 正常广播
自画 A 版（同固件）	✅ 正常广播
自画 B 版（同固件）	❌ 完全搜不到
B 版刷官方 HID 例程	⚠️ 能搜到，但信号很弱

B 版「完全搜不到」的硬件真因：22µH 电感虚焊，DCDC 没起来

后续定位到：B 版的内置 DCDC 功率电感（22µH）虚焊（空焊 / 立碑），DCDC 无法正常工作。把内置 DCDC 关掉、改由 LDO 直供后，立刻就能搜到广播信号——但信号十分微弱（B 版本身还有结构 / 工艺损耗，见实战指南 B 版案例）。叠加上「睡眠 + BLE」固件：硬件先把射频供电搞弱（DCDC 电感虚焊），固件一侧睡眠唤醒再一关，就成了「完全搜不到」；而官方 HID 例程没走睡眠、且绕开了 DCDC 异常，还能勉强发个弱信号。所以 B 版的根因是硬件（DCDC 电感虚焊）+ 固件（睡眠唤醒）两层叠加，别只怪一边。

关键判断：

B 版刷官方 HID 例程能发 → 射频前端、馈线、天线至少能辐射，硬件不是硬死（短路 / 断路 / 32M 没起的话 HID 也该没信号）。
信号很弱 → 印证结构 / 工艺损耗（阻抗失配 + 天线未随板厚重调 + 地篱笆可能缺失），是「弱」不是「死」。详见阻抗计算实战指南：B 版案例。
自己的「睡眠 + BLE」固件在 B 版完全静默，而在 A 版 / 淘宝板正常 → 根因指向固件侧，不是板子死。

二、CH582M 上 BLE 与低功耗的关系¶

BLE 物理层（PHY）靠 32 MHz 高速晶振产生射频时钟。任何深睡模式都会关掉 32M 时钟以省电，唤醒后必须重新把时钟和射频拉起来，PHY 才能工作。

典型 BLE 外设的节律（TMOS 任务调度）：

广播间隔到了 → 唤醒 → 重新起 32M → 重建 RF → 发一包广播；
发完 → 进低功耗睡眠，等下一个 RTC（32K）节拍；
循环往复。

关键点：这个「睡 → 醒 → 重建 RF → 再睡」的闭环，必须由 BLE 协议栈的低功耗管理器（TMOS LP handler） 来驱动。如果你绕开协议栈、自己写裸睡眠，射频不会自动恢复。

三、六个坑（固件侧）¶

先排除硬件，再查固件

在怀疑固件前，先刷官方 BLE / HID 例程确认硬件能发（哪怕弱）。若官方例程也完全搜不到，那是硬件问题（见实战指南 B 版案例），不是本文范畴。

坑 1：用裸 `SYS_SLP` / 仅 GPIO 唤醒，而非 BLE 低功耗入口¶

深睡关了 32M 和 RF 域。若你直接进裸睡眠、用外部 GPIO 唤醒，唤醒后协议栈并不知道要重建射频 → 完全静默。正解：走 BLE 栈提供的低功耗睡眠接口（让 TMOS 在睡眠间隙调度广播），不要裸眠。

坑 2：唤醒源没包含 32K RTC¶

BLE 靠 RTC 节拍触发下一次广播。若唤醒源只配了 GPIO、没配 32K RTC，芯片睡死不醒、或醒了也不按间隔广播。正解：低功耗唤醒源必须包含 32K RTC（且 RTC 在睡眠期间保持运行）。

坑 3：深睡关了 RF 电源域（VINTA）且唤醒没重使能¶

CH582M 内部有射频 LDO（VINTA ≈ 1.04 V，实测正常说明供电在）。若你的睡眠流程把 RF 电源域关掉、唤醒又没重新使能，射频直接死。排查：量唤醒后 VINTA 是否回到 ~1.04 V。

坑 4：唤醒后没等 32M 稳定就操作射频¶

32M 起振需要时间。若唤醒后立刻发广播、没等晶振 / PLL 锁定，会发异常或发不出。正解：遵循官方例程的「唤醒 → 等时钟稳定 → RF 初始化 → 发」时序。

坑 5：广播没在睡眠循环里被调度¶

有些「自己写的主循环 + 睡眠」忘了在每次唤醒后调用 BLE 广播 / TMOS 任务，于是睡眠占了绝大多数时间、广播从不执行 → 搜不到。正解：广播调度交给协议栈，主循环只负责业务，不要自己抢调度。

坑 6：把「硬件弱信号」误判成「固件没发」¶

B 版硬件本就弱（结构损耗）。若固件唤醒时序稍有瑕疵，弱信号会被彻底淹没成「搜不到」，让人误以为固件完全没发。正解：用 nRF Connect 看 RSSI 量化——能找到但 -40dBm 是硬件弱；完全找不到才是固件断。

四、排查 / 验证步骤¶

关睡眠、跑连续广播：把固件里的睡眠去掉，只跑连续 BLE 广播烧进 B 版。
能搜到（弱）→ 证明固件 RF 初始化对 B 版硬件 OK，bug 在睡眠 / 唤醒；
仍搜不到 → 是固件 RF 初始化与 B 版硬件的交互问题（但 HID 能发，概率低）。
逐步加睡眠：先在连续广播上叠「空闲睡」，再叠「间隔睡」，定位是哪一步开始断。
对照官方 BLE 例程：用 WCH 官方 BLE 外设例程（非 HID）在 B 版跑，作为「正确低功耗 + BLE」基准。
量化 RSSI：nRF Connect 看信号强度，区分「硬件弱」与「固件静默」。
量 VINTA / 32M：唤醒后 VINTA ≈ 1.04 V？32M 两引脚是否起振（~1 Vpp）？

五、正确做法的方向（待补具体代码）¶

使用 BLE 栈的低功耗入口，让 TMOS 在睡眠间隙自动调度广播与 RF 重建；
唤醒源配置包含 32K RTC；
不要在应用层裸睡眠；若必须，唤醒后完整走「时钟 → RF 初始化 → 广播」流程；
长续航靠「大 Iq 低的 LDO（如 SGM2034）+ 协议栈低功耗调度」组合，见 KeyGo-LDO 电源选型。

本文初稿未附可抄代码，因为尚未看到你的实际睡眠实现。等你定位到具体断点（坑 1~5 哪一个），把对应修复片段补进「正确做法」一节。

六、与硬件层的关系¶

B 版「搜不到」是两层叠加：

硬件层：结构 / 工艺导致信号弱（HID 弱信号为证）；
固件层：睡眠 + BLE 唤醒流程没把射频拉起来 → 完全静默。

不能只归一个。硬件弱的排查见阻抗计算实战指南的 B 版案例；本文负责固件层。