这款名为“Eye-Therapy Wearable Taps ST’s STM32 Wireless MCU”的智能眼罩式治疗设备是我最近接的一个可穿戴医疗方向的项目。熟悉这个领域的朋友应该知道眼周护理、视疲劳缓解、甚至儿童弱视辅助治疗这类产品现在最大的痛点不是功能堆料而是“体验”和“安全”的平衡既要无线控制、又要足够小巧、还要在贴近眼球的部位保持绝对稳定。最终我们选择以 ST的STM32WB55 系列双核无线MCU作为主控把BLE通信、电机驱动、恒温控制、LED光疗全部塞进了一个不到70克的眼罩里。这篇就围绕这个标题把整个项目的选型思路、硬件架构、固件实现和调试踩坑完整拆开给同样在做可穿戴设备或STM32无线应用的朋友一份参考。开始之前先说明一下文章里提到的所有具体方案和经验都来自我们实际走过的路但产品本身还在迭代很多细节我会用通用表述展开重点放在可复现的方法论上。如果你是第一次碰STM32WB或者正准备上一款带蓝牙的可穿戴医疗设备这篇的硬件选型和低功耗思路尤其值得细看。1. 项目整体设计与需求拆解1.1 产品定义与核心功能“Eye-Therapy Wearable”说白了就是一个智能护眼眼罩但和普通蒸汽眼罩不同它不止发热还集成了振动按摩、红光/红外光疗、以及后续要加的微电流刺激功能。用户通过手机App调节模式、温度和按摩强度设备端需要实时响应并且把运行状态电池电量、当前温度、治疗剩余时间回传手机。在设计之初我们列了五个刚性需求整机重量控制在75克以内佩戴舒适不压眼眶。单次充电至少支持三四次完整治疗流程每次约15分钟。BLE连接稳定App操作延迟不超过300毫秒。眼部接触部位表面温度必须控制在41℃以下靠NTC闭环。整机通过家用医疗电器的安全规范至少是“心理上”按医疗级设计。这几个需求直接决定了MCU选型方向。市面上一堆蓝牙SoC比如Nordic nRF52系列、Dialog DA14531甚至国产的奉加、泰凌微都各有优势。但考虑到我们需要同时跑电机PWM控制、温度PID、LED光疗时序、电池管理还要留出一部分算力给后续算法升级主频太低的单核芯片就会捉襟见肘。STM32WB55这颗芯片恰好是双核架构Cortex-M4跑应用Cortex-M0独立跑BLE协议栈两边各干各的互不拖累开发体验和调试效率都要好很多。1.2 为什么是STM32WB而不是“MCU外部蓝牙模块”现在很多硬件团队习惯用“一颗普通MCU 一颗BLE透传模块”来降低风险但在这个项目里我们坚持用单颗STM32WB原因有三第一成本。BLE透传模块比如nRF52832模块单颗下来也要十几块再加上主控MCU十几块物料成本轻松超过35元。而STM32WB55RG单颗批量价大约25元上下还能省掉两片之间连接用的UART、电源和电平转换PCB面积也小了。第二实时性。传统双芯片方案里主控MCU和蓝牙模块通过串口通信数据包经过协议栈封装、发送、再解析带来的延迟和不确定性在医疗设备里很致命。STM32WB的双核之间通过内部IPC邮箱通信哪怕App下发的指令到了BLE协议栈M0核也能在几百微秒内通知M4应用核处理完全能够满足实时控制。第三安全与OTA。医疗类可穿戴设备要支持固件升级而且必须保证升级过程不会变砖。STM32WB自带bootloader和无线OTA分区方案ST官方提供了整套例程配合双核的FUSFirmware Upgrade Service机制可以做到App核和协议栈核分别升级比自己做外挂模块的OTA可靠很多。维度STM32WB55RGMCUBLE模块说明成本中高高单芯片优势明显实时性高中双核IPC延迟低外围接口丰富受模块限制多路定时器/ADC开发复杂度中低但联调高需要理解双核OTA安全性高中官方FUS方案成熟1.3 面向可穿戴场景的核心需求拆解可穿戴医疗设备和普通消费电子最大的差别在于“连续物理接触”和“人在回路”的安全要求。具体到这款眼罩需要重点关注几个子系统热管理加热膜不能直接由GPIO通断控制需要PWM配合NTC形成闭环并且出现温度超限时要能及时切断。电机驱动两个振动马达左右眼各一个需要独立调速同时不能干扰蓝牙射频。电源管理电池充放电、电量检测、低电量提醒以及低电量时自动停止加热。通信BLE连接参数需要平衡功耗和响应速度还需要支持断线重连、被动广播。这些需求共同指向一颗具备丰富模拟外设、定时器资源充足、并且对低功耗模式支持良好的MCU。STM32WB55恰好满足了这些要求。它的ADC是12位16通道Timer资源够用总共15个而且有着完整的STOP2低功耗模式可以在保持BLE连接的情况下做到极低的系统功耗。2. 硬件架构与核心电路设计2.1 MCU选型与最小系统设计我们选了STM32WB55RGV664脚LQFP封装理由很简单——资源和体积的折中。512KBFlash、256KB SRAM足够保存用户配置和一部分日志。LQFP64也比QFN更利于手工焊接调试原型阶段很友好。最小系统设计上有几个容易踩坑的点射频部分STM32WB55的RF需要一个外接Balun电路官方推荐使用单端50Ω的ipd集成无源器件方案。我们照着ST推荐的参考资料“AN5165”画了参考设计天线选择了PIFA天线形式放在眼罩头带转折处。这里特别提醒一句天线周围不要铺地和走线净空区是射频性能的命根子后面调试距离不理想多半就是天线区域被马达和电池挤占了。晶振32MHz主晶振用的是12MHz不对STM32WB的RF需要32MHz外部晶振。这款芯片必须要有低速32.768kHz晶振否则BLE的sleep时钟不准连接参数漂移会导致频繁断连。我们最初为了省成本用了便宜的国产晶振结果在温度变化时频率偏移达到±30ppmBLE连接极不稳定后来换成了±10ppm的温补晶振才解决。复位与调试把SWD引脚留出来同时注意在调试模式下禁用看门狗否则一边调试一边复位你就等着被折磨吧。2.2 电源树与低功耗供电设计供电链路采用单颗3.7V锂电池经过LDO降到3.3V给整个系统供电。为什么不用DCDC因为眼罩内部空间太小DCDC的电感容易产生磁场离马达和NTC太近干扰难排查。而且整体系统电流不大加热时最大800mALDO的损耗在可接受范围内。电源设计的关键在“分级供电”MCU供电、传感器供电、马达驱动供电三者之间用磁珠和π型滤波隔离开。马达驱动使用一颗峰值电流1A的H桥芯片PWM频率20kHz通过MCU的定时器输出两路互补信号控制。NTC测温使用3.3V经过10kΩ精密电阻分压后接到ADC通道采样前加RC滤波防止高频噪声干扰。电池电量检测这里踩过最经典的坑直接用MCU的ADC引脚接电池正极分压结果电池从4.2V掉到3.6V之后ADC读数波动很大。这是不可避免的因为马达和加热膜工作时电池内阻压降明显。解决办法是检测“开路电压法”在每次治疗结束且负载关闭50ms后采样一次电压用查表法映射到电量百分比。这个方案简单可靠我们最终把它做进了固件。2.3 电机、加热与LED驱动细节振动马达选了空心杯式扁平马达转速5000rpm时额定电流约80mA两路并联后由PWM驱动。因为马达启动瞬间会有浪涌我们在供电入口并联了一颗470uF聚合物电容并在软件里做了软启动——PWM占空比从0逐渐提升到目标值这样既避免了电源电压塌陷也减少了马达振动时的噪音。加热膜用的是柔性PTC加热片工作电压3.7V常温阻值约4.5Ω最大功率3W。通过一颗N-MOSFET做低边开关由定时器PWM控制功率。温度闭环放在M4核上运行NTC采样10次取平均PID周期为200ms。实测在室温25℃环境下眼罩接触表面温度可以稳定在40℃±0.5℃达到了预期。红光和红外光疗部分选用了波长660nm的红光和850nm的红外光LED分别布置在眼眶周围。LED驱动采用简单的三极管恒流电路每路最大电流20mA由定时器控制亮度渐变避免突兀点亮造成刺眼。这部分硬件相对简单但要注意LED的焊盘和走线一定要做足够宽的铜箔散热否则柔性电路板局部高温很麻烦。3. 固件架构与核心功能实现3.1 CubeMX工程配置与双核启动流程固件开发基于STM32CubeIDE首先用STM32CubeMX生成双核工程框架。很多刚接触STM32WB的朋友会被它复杂的启动方式搞晕——两颗核各有各的flash、RAM和中断M0核其实充当的是“协议栈执行者”它运行的BLE协议栈固件由ST提供我们只需要编译好M0工程再烧录到固定flash区域。具体到CubeMX里的配置将M4作为主核启动时先执行系统初始化然后启动M0核。M0核的hex文件需要放在指定起始地址比如0x08000000协议栈专用区域。在M4工程里调用SHCI_C2_BLE_Init()函数传入BLE协议栈的配置参数比如广播间隔、连接间隔、事件长度等。这里有个容易犯的错误两个核共用同一个Flash烧录时如果只烧了M4的固件而忘了合并M0的协议栈M4启动后会卡在等待C2BLE事件响应的循环里。我们后期直接在烧录脚本里合并两个hex文件一键烧录省心很多。双核通信采用ST的IPC库。M4向M0发送BLE命令以及M0向M4上报BLE事件都是通过共享内存和硬件信号量完成的。应用层不需要直接操作底层寄存器直接调用API就行比如BLE_Stack_Init()、Aci_Gap_Set_Advertising_Data()等。3.2 应用层任务调度与RTOS选型整个应用层如果裸奔写状态机后期加功能会很痛苦所以我们直接上了FreeRTOS。利用STM32CubeMX的中间件集成功能一行代码都不用手写自动生成RTOS工程。任务划分如下BLE_Process处理BLE事件和命令解析优先级较高每10ms轮询一次。Therapy_Control治疗流程状态机控制按摩、加热、LED的组合50ms周期运行。Safety_Monitor监控NTC温度、电池电压、看门狗喂狗500ms周期运行优先级最高。Power_Management处理充电和低电量保护优先级最低空闲时运行。这种结构的好处是即使BLE任务堵塞安全监控任务依然能独立运行关键时候能救回来。比如有一次我们在调试马达PWM的极速变化时M4核因为浮点运算过载导致温度PID未及时更新NTC温度一路窜到设定值以上安全监控任务直接切断加热PWM输出避免了危险。没有RTOS和任务隔离这种故障大概率发现不了。3.3 不可忽略的低功耗策略可穿戴设备的功耗设计贯穿整个固件而不是简单地睡眠加唤醒。STM32WB55在BLE连接状态下可以做到2.4GHz射频和M4核心都进入低功耗模式。我们的低功耗策略分为三层空闲时M4进入STOP2模式仅保留RTC和低功耗定时器。BLE连接保持由M0核独立处理M4通过IPC唤醒事件返回运行态。治疗过程中关闭BLE的通知传输只有在状态变化时才主动向上推送降低radio唤醒次数。对传感器采样频率做降频NTC从10Hz降到1Hz马达PWM的频率不变但通过调整占空比来减少驱动功耗。实测下来待机广播模式无连接平均电流约11uABLE连接且无治疗操作时整个系统平均电流约55uA——这个数据是采用负功耗的“等间隔采样法”测出来的用电流探头挂在电源上连接后观察电流波形并取平均。有朋友问过能不能直接在STOP2模式下用HAL_Delay()实现延时答案是不行。HAL_Delay()依赖SysTick中断STOP2模式下SysTick已经停了执行延时会导致死等。我们统一改用osDelay()在RTOS中由Systick调度必要时配合RTC_WakeUp来实现长周期唤醒。3.4 眼部治疗流程的具体实现治疗流程是核心使用体验。我们把模式分为三档舒缓模式加热40℃马达低速红光弱光总时长15分钟。活力模式加热40℃马达中速脉冲式震动混合红光和红外光总时长12分钟。深睡模式加热38℃马达关闭红外光从强到弱渐变总时长20分钟。每次治疗开始前先检测温度是否已经达到目标如果没有则先加热再启动马达和LED。治疗过程中每5秒向手机推送一次当前温度和剩余时间。用户随时可以在App上暂停或结束治疗。这个流程的实现并不复杂核心是用一个状态机把每个阶段的持续时间和动作数组化。但因为状态机要跨多个任务访问要注意对共享变量的互斥保护。我们直接在每个状态机的入口处加taskENTER_CRITICAL()和taskEXIT_CRITICAL()虽然简单粗暴但在这个低负载场景里完全够用。4. BLE连接与手机App交互4.1 GATT服务设计BLE连接质量是整个产品的口碑所在。GATT服务设计直接决定了App开发的难度和后期扩展性。我们定义了一个自定义服务包含四个Characteristic设备信息只读设备ID、硬件版本、固件版本UUID为0xFFF1。控制指令写入App下发模式、力度、时长UUID为0xFFF2。状态上报通知设备上报当前状态UUID为0xFFF3。OTA升级写入指示触发升级UUID为0xFFF4。控制指令的数据帧格式是JSON还是二进制我们最终选了二进制。原因很简单BLE MTU默认只有23字节扩展后的MTU也就247字节左右JSON的开销太大解析还费电。数据帧定义成固定8字节的二进制结构帧头、指令码、参数1、参数2、校验和、帧尾。App和MCU端都把这套打包解包逻辑做成独立模块方便复用。4.2 连接参数与稳定性的调优BLE连接稳定性问题最让人头疼。最初我们将连接间隔设为11.25ms从机延迟设为0看起来数据很“实时”但实际使用时会发现设备功耗高、并且手机偶尔会丢失几个通知包。原因在于连接间隔太短会让射频工作占空比过高加上天线被马达遮挡丢包率随之上升。经过逐步试验最终参数定为连接间隔30ms从机延迟4超时时间4000ms。这种配置下理论数据速率满足控制需求而且理论上单次连接事件功耗比原来降低了约70%。实际测试中手机靠近和远离眼罩10米以上都能维持稳定连接几乎没有感知到断连或重连延迟。提示连接参数最好在设备端设置而不是依赖手机App中心设备去协商。STM32WB的GAP层支持设置“从机参数建议”我们固件里强制指定了这个参数表防止某些安卓手机强行采用激进连接参数。4.3 App侧开发与测试工具App端我们先用开源的nRF Connect调试通了所有功能之后才交给正式团队的安卓/iOS工程师对接。单独做App界面周期长但是BLE协议验证阶段建议先用现成工具完全跑通再开发正式App能省下大量排错时间。正式App上我们实现了三大页面设备列表页扫描附近的眼罩设备同时显示信号强度和电量。治疗控制页选择模式、调节参数显示实时温度曲线。数据统计页记录每周使用时长、模式分布、历史治疗完成率。开发过程中最有用的调试工具是ST的STM32CubeMonitor-RF可以直接抓取BLE广播包和连接事件还能看射频信号强度、信道占用情况。如果遇到连接闪断强烈建议先用它抓包确认是射频干扰还是协议层异常再动手改代码别一上来就调连接参数。4.4 OTA在线升级的实现要点医疗可穿戴设备没有OTA支持简直没法用。我们把STM32WB的FUS方案直接融入了工程。Stm32WB的OTA分两部分协议栈升级M0核通过FUS服务进行需要把新协议栈固件放到固定区域再通过系统Bootloader引导。应用固件升级M4核采用ST的“双Bank”机制把应用区分为Bank1和Bank2升级时先将新固件写入Bank2校验成功后切换Boot指向再重启。App升级流程设计为App从服务器下载固件包通过BLE分800字节一包发给设备设备写入外部Flash其实不需要外部FlashSTM32WB的Bootloader支持通过BLE直接写入内部Flash但要注意M4核的Flash同时还在跑代码如果不使用双Bank机制就无法边跑边升级。双Bank模式下MCU从Bank1运行Bank2可以同时写入。每次OTA升级大概需要传输150KB固件按照我们设的BLE MTU 247字节、每包有效数据230字节估算全速传输约10分钟。我们做了断点续传和校验实测OTA成功率在98%以上。5. 常见问题与调试心得5.1 双核通信卡死与调试对策STM32WB开发中最大的坑就是“M4启动后收不到BLE事件卡在初始化”。有一次我们把M0核的协议栈初始化放在系统时钟初始化之前结果M4运行到BLE_Stack_Init时永远停在等待事件标志位。排查了整整一天最后发现是M0核的固件烧录版本和M4的库版本不匹配。ST的协议栈固件更新很快不同版本之间API有改动如果M4库的版本比M0核里烧录的栈版本新初始化就会静默失败。建议流程是每次去ST官网下载最新的STM32CubeWB软件包对整个工程重新生成一次并严格按照“先烧M0栈、再烧M4应用“的顺序烧录。我们把这个步骤写进了CI脚本避免人为操作失误。5.2 BLE广播偶尔丢失App扫描不到设备这个问题说起来很玄但很常见。初期我们调试时发现如果电池电量低于3.4VBLE广播就会出现间歇性丢失。拿示波器抓3.3V电源轨发现瞬态电压跌到2.8V低于射频前端的最低工作电压。原因是电池在低温或低电量下的内阻偏大加上马达瞬间启动电流将LDO输入电压拉低。解决办法有三个方向一是把加热和马达的启动时序错开避免同时启动二是在电源输入端加大容量储能电容三是把BLE广播事件安排在电机PWM的关闭窗口内。第三种方法听起来玄但STM32WB的射频事件是可以与M4任务时间轴同步的将BLE广播周期与PWM关断时间对齐后再也没出现过扫描时断时续的问题。5.3 电池电压采样漂移电量显示不准前面提过电量检测这里再展开一个细节。我们的电池电压采样在10s内做了20次取平均但依然有±0.15V的波动。后来发现波动和NTC使能状态强相关——NTC分压网络与电池电压采样共用了ADC通道不是是两个独立的ADC通道但是在PCB布局上NTC的模拟地走线和电池分压的地线在ADC参考地附近重合导致回流噪声串入。解决方法是把两个模拟信号的地线分开走并且每个信号源都串接一个50Ω电阻再接ADC引脚再对地并联100nF电容。重新打样后电压采样稳定度提升了一个数量级。5.4 马达PWM对蓝牙射频的干扰这是一个硬件和软件交叉的问题。马达是直流有刷电机换向时产生火花和宽带噪声会直接掩蔽BLE信号。我们最初在电机电刷两端并联了一颗0.1uF电容但作用不大。后来在驱动信号线上加了一颗共模电感同时在PCB上电机驱动走线尽量远离天线馈点效果明显。软件上把电机PWM频率从20kHz提高到30kHz避开蓝牙信道的谐波2.4GHz频段附近并且在PWM极性切换时等待500us再发送BLE包有效降低了重传率。5.5 常见问题速查表现象可能原因解决对策BLE连接频繁断开连接间隔太短 / 晶振偏差大调整连接间隔、换低温漂晶振设备广播但手机搜不到电池电压低 / 天线净空不足加大储能电容、调整天线区域M4卡死在BLE初始化M0协议栈版本不匹配复用配对的CubeWB版本温度控制超调NTC采样滤波不够 / PID参数不对增加均值滤波、调节PID电池电量跳变负载导致电源跌落增加采样序列、在空载时采样马达噪声很大驱动频率落在人耳敏感区PWM频率调高到25kHz以上6. 量产与认证过程中的补充分享这个项目从原型到试产我们还积累了一些和“做出来”完全不同的经验。如果你只是做一套演示样机下面的部分可以略过但如果想做成产品这些内容早晚会碰到。6.1 物料挑选与国产化替代STM32WB55的供应目前相对稳定但基于成本考量我们也测试过几款国产替方案结论是短期内不会换。原因是BLE协议栈的授权问题很麻烦ST的协议栈免费且经过大量商用验证国产芯片很多协议栈是商业授权或不够成熟。不过元器件的国产化替代还是有空间的比如马达驱动芯片从TI的DRV8837换成了国产的GC8553实测性能接近成本降低约40%LDO用圣邦微的SGM2036噪声和压差都不错。对有量产计划的朋友建议在原理图阶段就要留出可替代封装别把PCB固定死在一个供应商上这个行业缺货是常态。6.2 安全性与可靠性测试重点眼罩类产品虽然不属于严格意义上的三类医疗器械但涉及热源和人体接触可靠性测试要做得很细。我们的测试清单里除了常规的跌落、浸泡、冷热冲击之外还专门做了“异常断电测试”在任意治疗阶段突然拔掉电池重新上电后设备要能恢复到待机状态且加热PWM必须保持关闭防止意外重启后继续加热。另一个重要测试是“低温环境启动测试”模拟冬天室外刚戴上的场景。我们发现如果电池温度低于5℃电池电压会被拉低到3.0V以下MCU可能在启动过程中反复进入欠压复位。为了解决这个问题固件里增加了“冷启动延迟检测”如果系统上电后检测到电压偏低就先进入低功耗模式等待电池温度回升再完成初始化。这个功能虽然简单但在用户评价里却很少被注意到然而它对设备可靠性的影响很大。6.3 产线烧录与出厂校准这个项目到了试产阶段烧录环节同样要注意。我们使用ST-LINK/V2的批量烧录模式把M0协议栈和M4应用固件整合到一个hex文件里配合ST官方工具一次性烧录完成。因为每台设备的NTC电阻和马达差异出厂前需要做一次“校准”在出厂测试工装中自动完成三件套校准NTC偏差、马达PWM占空比阈值、电池电压采样偏差。校准数据保存在Flash的独立扇区应用启动时读取。很多中小团队会跳过这步但我觉得这是保证体验一致性的关键。每一个马达的起振电压都不同如果不校准默认PID参数会把每个设备的实际温度和App上显示的温度偏差拉到三四度用户体验就会很不稳定。7. 给后来者的一些个人体会做这个项目过程中我最大的感受是STM32WB确实是眼下做可穿戴设备最舒服的芯片之一但前提是你得把它当成“一个双核系统”来对待而不是当成一颗传统单片机。双核带来的是任务分离的清爽同时也带来了调试上的心智负担。如果你手头也要做一个类似的眼健康设备我会建议第一次打样时就把天线净空区和电源域隔离设计好不要为了缩小PCB面积牺牲这两点。否则后面每调一个功能射频和电源噪声都会跳出来捣乱你会怀疑人生。还有一个小技巧ST官方社区里有一个专门的STM32WB板块很多问题都能搜到参考。我在调试BLE OTA和双Bank切换时靠的就是社区里一篇老帖子里的片段。做嵌入式不可能不踩坑但把坑记录和分享出来是大家集体提升效率的唯一办法。这个项目目前还在小批量验证阶段后续如果有新的测试数据和功能迭代我再回来更新。如果你也正好在评估STM32WB做无线可穿戴方案欢迎在评论区交流具体问题我知道的都会尽量解答。