BlueNRG上Flash擦写与BLE事件互斥调度的工程实践

去年做一款带数据记录功能的BLE传感器时我踩过一个特别典型的坑设备在连接状态下每5秒想把采集到的数据写进片内Flash结果手机App上每隔一会儿就提示“连接已断开”。一开始我怀疑是天线问题后来用BLE分析仪抓包才发现每次断链的时间点都刚好卡在Flash页擦除函数返回前后。那一刻我才认真去读BlueNRG手册里关于Flash操作和BLE协议栈事件调度的说明也才有了这篇笔记。如果你也在用ST的BlueNRG-1/BlueNRG-2这类单核BLE SoC并且需要在运行中保存参数、记录日志或更新配置那这篇内容你应该用得上。这篇文章会从头解释为什么Flash擦写会和BLE事件抢CPU再给出几种可落地的互斥调度方案最后附上我实际调试中整理的排查思路和代码框架。内容偏向工程实践不是抄手册所有方法都在真实项目里验证过。1. 问题根源Flash擦写为什么会干扰BLE事件1.1 BlueNRG的存储架构和Flash操作特性BlueNRG系列是ST的BLE单芯片方案把Cortex-M0/M0内核、射频收发器、片上Flash和RAM集成在一颗芯片里。用户应用程序、BLE协议栈以静态库形式提供和射频驱动全部跑在同一个CPU上。这和“MCU外部蓝牙模块”的结构有本质区别模块方案里MCU写自己的Flash不会影响蓝牙芯片但BlueNRG里所有任务共享一个核任何长时间占用的操作都会挤压BLE协议栈的处理时间。片内Flash用于存放代码和用户数据。用户实际会用到的Flash操作大致分三类页擦除Page EraseFlash写入前必须先把目标区域擦成0xFF擦除粒度是一个page。BlueNRG-1和BlueNRG-2的页大小不太一样典型值在1KB到2KB这个量级具体以对应型号数据手册为准。字编程Word Program按32位字为单位写入数据写入前目标区域必须是已擦除状态。NVDSNon-Volatile Data Storage这是ST提供的非易失数据存储机制由协议栈维护一部分用户也可以使用保留槽位。NVDS底层依旧是Flash操作但内部做了擦写管理和数据组织。关键问题在于Flash控制器执行擦除或编程时会独占Flash阵列。而Cortex-M内核的指令通常也是从同一片Flash取出于是CPU在Flash控制器忙的时候只能停顿等待。也就是说Flash擦写不只是“执行一些代码”那么简单——它是一个硬阻塞窗口期间中断响应会被延迟指令取指会停止BLE协议栈哪怕想做点什么都做不了。这跟很多人熟悉的STM32外部SPI Flash完全不一样。外挂SPI Flash通过SPI接口读写CPU可以一边等SPI传输一边干别的但BlueNRG内部Flash是CPU取指的直接来源擦写期间整个内核都被“锁住”这是所有互斥问题的物理根源。1.2 BLE协议栈事件处理的时间敏感点在哪里BLE链路层是严格时分复用的。连接建立以后主设备和从设备按固定的连接间隔Connection Interval互相收发数据每个连接事件里要完成交换、确认、重传等动作。如果从设备在连接事件到来时没有及时处理主机那边就会丢包、重传连续错过多个事件后连接监督定时器Supervision Timeout超时链路直接断掉。广播模式类似每个广播间隔要发一个广播包如果CPU正卡在Flash擦写上广播包就会被推迟甚至漏发手机端表现为扫描不到设备或者广播数据不刷新。BlueNRG的协议栈通过事件队列和应用层交互。射频中断或者协议栈内部定时器到达时底层会把事件打包放入HCI事件队列用户程序在主循环里调用BLE_EvtRx()查询、调用HCI_Event_Processing()消费处理。这本身就是异步设计正常情况下完全够用。但问题是用户代码如果在主循环里长时间执行Flash擦写HCI_Event_Processing()迟迟得不到调用队列越积越多链路层状态机得不到及时推进最终就是断链。还有一个很多人容易忽略的点即使你把Flash操作放在一个定时器中断里或者放在一个“看起来优先级很高”的位置也无法绕过这个阻塞。因为Flash控制器忙时CPU连中断服务程序的指令都无法从Flash取出中断响应被硬件层面延后。所以这不是软件调度优先级能解决的问题必须在时间窗口层面做统筹。1.3 复现现场一次Flash页擦除带来的断链实验为了把问题讲清楚我在BlueNRG-2评估板上做了一个简单实验。测试环境BlueNRG-2评估板作为从设备手机用nRF Connect连接连接间隔设置为30ms连接监督超时设置为4s。代码里在收到一个特定写指令后触发一次整页Flash擦除典型值约20~40ms以具体芯片手册为准擦除完再写入64字节数据。现象记录得很清楚连接间隔30ms时一次页擦除大约跨过1~2个连接事件连接没有断但手机端看到明显的通信延迟RSSI曲线出现周期性波动。连接间隔缩短到15ms后同样的擦除操作导致连续丢包部分Android手机直接报连接不稳定。如果把连接监督超时从4s改小到1s再将Flash擦除操作连续执行多次模拟批量写日志连接几乎必然断开。这个实验说明一个问题并不是“只要Flash操作时间小于监督超时时间就安全”因为断链的临界条件不仅取决于总超时还取决于你让主机“等”了多久、丢了多少包。链路不稳定一样会影响产品体验不是只有彻底断开才算故障。2. 互斥调度的四种方案从主循环空闲窗口到NVDS2.1 方案一主循环空闲窗口里执行Flash操作最直接也最容易被接受的思路是在主循环处理完所有BLE事件之后利用事件与事件之间的空闲时间做Flash操作。典型代码如下while (1) { /* 1. 优先把BLE协议栈事件全部处理完 */ while (BLE_EvtRx()) { HCI_Event_Processing(); } /* 2. 用户应用业务逻辑 */ user_app_task(); /* 3. Flash写入任务只在空闲窗口执行 */ flash_task_scheduler(); /* 4. 进入低功耗或继续循环 */ }这个方案的核心逻辑是先让协议栈把当前所有事件消费干净再做自己的耗时操作。它实现最简单适合两种情况设备处于未连接状态只是偶尔更新参数或者连接业务的实时性要求不高。但它的局限也很明显。BLE事件是持续到达的你处理完当前事件队列只是一瞬间下一个连接事件可能就在几毫秒后到来。如果在flash_task_scheduler()里执行了一次40ms的页擦除下一次连接事件照样被堵住。所以这个方案只适合“操作时间远小于连接间隔”的轻量写入不适合批量日志写入或大块数据更新。2.2 方案二拆写不拆擦用状态机让BLE事件插队针对Flash写操作的耗时主要来自两部分擦除和编程。擦除是一次性动作很难拆碎但编程可以按字拆每写一个字大约几十微秒几十微秒对BLE连接事件来说是一个可以容忍的窗口。于是可以把“写一大块数据”拆成“多次写一小块数据”每写完一小块就检查一次BLE事件队列有事件就先让协议栈处理处理完再继续写。void flash_write_chunk(void) { if (g_flash_op.offset g_flash_op.length) { g_flash_op.state FLASH_OP_DONE; return; } /* 每次只写一个字32位时间很短 */ FLASH_Program(g_flash_op.dst_addr g_flash_op.offset, g_flash_op.src_data g_flash_op.offset); g_flash_op.offset 4; /* 写完一个字之后主动让出有BLE事件就返回主循环 */ if (BLE_EvtRx()) return; }但是必须提醒拆写只在“编程”阶段有效页擦除这个动作是拆不开的。所以更完整的做法是把擦除和写入分成两个阶段先找一个足够宽裕的时间窗口执行页擦除然后利用多次小窗口逐字写入。对于需要跨多页的大块数据还要一页一页处理不能一口气把所有页都擦完。这个方案的核心价值是把“不可抢占的长时间段”尽量缩小让BLE事件在每两个字之间都有插队机会。代价是代码复杂度上升必须引入状态机管理写入进度否则断电中断后状态就丢了。2.3 方案三根据连接间隔选择安全写入窗口如果设备处于连接状态可以动态获取当前连接参数再决定Flash操作是否执行。BlueNRG协议栈提供了获取连接参数的接口比如aci_gap_get_connection_parameters()或者aci_hal_get_link_status()具体接口名以所用SDK版本为准。拿到连接间隔和监督超时后就能估算当前还有多少时间可以安全做Flash操作。一个保守的判断逻辑获取当前连接间隔conn_interval和监督超时supervision_timeout。计算出单次Flash操作的最大允许时间比如页擦除需要约T_erase毫秒。如果T_erase远小于监督超时并且能保证在下一个连接事件到来之前完成就执行否则推迟到下一个连接间隔再试。实际做的时候我还会配合L2CAP连接参数更新请求aci_l2cap_connection_parameters_update()调整连接参数。比如在需要批量写Flash前临时请求把连接间隔从15ms放宽到50ms给链路层留出更多空闲窗口写完再调回来。这个方法很有效但代价是连接带宽下降、数据延迟变大不能频繁使用否则会影响正常业务。还有一个更精准的窗口计算方式用协议栈提供的系统Tick获取当前距离下一次连接事件的时间如果这个剩余时间大于“Flash操作时间余量”就执行操作否则直接放弃本轮。这样可以在不调整连接参数的情况下尽量把Flash操作塞进连接事件间隙里。2.4 方案四用NVDS替代裸Flash操作很多场景下用户根本不需要直接操作Flash用NVDS就够了。NVDS是协议栈维护的非易失数据区用来保存设备地址、绑定信息、配对密钥等。同时它向用户开放了一批槽位可以存自定义参数。BlueNRG SDK里提供了NVDS读写接口用法大致如下#define USER_NVDS_ADDR 0x10 #define USER_NVDS_SIZE 64 uint8_t buf[64]; uint16_t len USER_NVDS_SIZE; /* 读取用户NVDS数据 */ GetNvdsUserData(USER_NVDS_ADDR, len, buf); /* 更新数据后写回 */ buf[0] 0xAA; WriteNvdsUserData(USER_NVDS_ADDR, USER_NVDS_SIZE, buf);NVDS的好处是内部处理了擦写对齐、数据管理和掉电保护逻辑你不需要关心底层哪一页要擦、哪一页要写。它本身也是一次Flash操作但通常针对小数据量做了优化阻塞时间比直接整页擦除要短。局限是用户槽位有限单槽容量一般不大常见为64字节级别具体见SDK头文件定义不适合存日志或大块二进制数据。如果你的存储需求就是保存几十字节配置参数NVDS是最省心的选择完全不用自己写Flash调度器。如果数据量超过NVDS能力再考虑自管理Flash区域或者干脆外挂一颗SPI NOR Flash。这四种方案不是互斥的在一个实际产品里经常组合使用。比如配置参数用NVDS保存运行日志用自管理Flash区域大块固件数据走外挂存储。我建议先明确自己的数据量、写入频率和掉电安全要求再决定用哪一层方案。下表是四种方案的对比方案实现复杂度实时性风险适用场景主循环空闲窗口低中未连接状态、写入频率低拆写不拆擦 状态机中低连接态下写日志、参数频繁更新连接间隔感知调度中高低连接态批量数据写入NVDS低低小容量配置参数存储3. 实操写一个带状态机的Flash写入调度器3.1 调度器的数据结构与状态机设计在正式项目里我最终采用的是“状态机 可让出”的Flash调度器。状态机的好处是每次操作只做一小步做完就退出由主循环决定是否继续中间随时可以被BLE事件打断断了下次接着做而且状态可读、可诊断出问题能定位是卡在擦除还是卡在写入。定义如下数据结构typedef enum { FLASH_OP_IDLE 0, FLASH_OP_PENDING, FLASH_OP_ERASE, FLASH_OP_WRITE, FLASH_OP_VERIFY, FLASH_OP_DONE, FLASH_OP_ERROR } flash_op_state_t; typedef struct { flash_op_state_t state; uint32_t dst_addr; const uint8_t *src_data; uint32_t length; uint32_t offset; uint32_t erase_page_count; } flash_op_t; static flash_op_t g_flash_op;状态转换逻辑IDLE没有待处理任务。PENDING有一笔Flash操作请求进来了还没开始执行。ERASE执行页擦除阶段。擦除完成后进入WRITE。WRITE逐字写入数据每次只写一个word写完检查BLE事件如果有事件就主动让出。VERIFY写入完成后回读校验确保数据正确。DONE操作成功完成。ERROR擦除或写入失败进入错误处理。之所以单独设置PENDING而不是在IDLE里直接执行是为了把“请求操作”和“执行操作”解耦。比如你在BLE事件回调里想写数据回调里只需要登记状态不需要立刻执行Flash操作这样天然避开了在回调里阻塞协议栈的问题。3.2 主循环集成与调度优先级调度器在主循环里的位置很关键。我自己的规则是BLE事件处理优先级最高用户普通任务其次Flash操作排最后。每次flash_scheduler_tick()执行前都会先问一句“现在允许操作Flash吗”不允许就返回让主循环继续跑。while (1) { /* 1. 优先处理BLE协议栈事件 */ while (BLE_EvtRx()) { HCI_Event_Processing(); } /* 2. 用户应用任务 */ user_app_task(); /* 3. 如果有待写数据注册Flash操作请求 */ if (user_data_dirty g_flash_op.state FLASH_OP_IDLE) { flash_op_start(USER_DATA_FLASH_ADDR, user_data_buf, user_data_len); } /* 4. 执行Flash调度器的一小步 */ flash_scheduler_tick(); }flash_op_start()只是把数据结构初始化并置为PENDING不做任何实际Flash操作void flash_op_start(uint32_t dst, const uint8_t *src, uint32_t len) { if (g_flash_op.state ! FLASH_OP_IDLE) return; g_flash_op.dst_addr dst; g_flash_op.src_data src; g_flash_op.length len; g_flash_op.offset 0; g_flash_op.state FLASH_OP_PENDING; }真正的执行逻辑放在flash_scheduler_tick()里每一步之前都检查是否允许继续static int flash_can_proceed(void) { if (BLE_EvtRx()) return 0; /* 如果连接是激活的检查距下一个连接事件是否足够远 */ if (conn_active conn_remaining_time SAFE_MARGIN) return 0; return 1; } void flash_scheduler_tick(void) { if (g_flash_op.state FLASH_OP_IDLE) return; if (g_flash_op.state FLASH_OP_PENDING) { g_flash_op.state FLASH_OP_ERASE; } if (!flash_can_proceed()) return; switch (g_flash_op.state) { case FLASH_OP_ERASE: /* 整页擦除一次性完成不做拆分 */ for (uint32_t i 0; i g_flash_op.erase_page_count; i) { FLASH_ErasePage(g_flash_op.dst_addr i * PAGE_SIZE); } g_flash_op.state FLASH_OP_WRITE; break; case FLASH_OP_WRITE: /* 每次只写一个字写完立刻退出 */ FLASH_Program(g_flash_op.dst_addr g_flash_op.offset, g_flash_op.src_data g_flash_op.offset); g_flash_op.offset 4; if (g_flash_op.offset g_flash_op.length) g_flash_op.state FLASH_OP_VERIFY; break; case FLASH_OP_VERIFY: /* 回读校验可选择在WRITE阶段分段校验 */ if (memcmp((void *)g_flash_op.dst_addr, g_flash_op.src_data, g_flash_op.length) 0) g_flash_op.state FLASH_OP_DONE; else g_flash_op.state FLASH_OP_ERROR; break; default: break; } }注意这里的FLASH_ErasePage和FLASH_Program是SDK底层驱动的抽象命名实际函数名要看具体SDK版本但功能是对应的。flash_can_proceed()里的conn_remaining_time来自连接参数和系统Tick的推算如果拿不到精确时间最简单的保守策略是只要BLE_EvtRx()有事件就立即让出。这个调度器看起来简单但解决了实际项目里90%的互斥问题。剩下10%是页擦除这种不可拆操作必须在更宏观的窗口里统筹。3.3 时间边界不同数据量的Flash操作对连接的影响做调度器之前必须清楚每种Flash操作到底要花多久。BlueNRG-1/2的典型时序具体数值以数据手册为准字编程32位几十微秒量级典型约60µs。页擦除一个page典型约20~40ms量级。读操作正常取指速度不构成阻塞。以这些典型值为基准做一些粗略估算写64字节参数如果使用NVDS底层通常先擦后写整体阻塞时间可以控制在几毫秒到几十毫秒级别。如果裸写Flash64字节 16个字编程时间约1ms如果之前还要擦一页再加约20~40ms总阻塞约21~41ms。写1KB数据1KB 256个字编程时间约15ms加一页擦除约40ms总计约55ms。如果连接间隔是30ms这已经跨过两个连接事件了。写4KB数据跨4页擦除4页约160ms编程约60ms总计约220ms。这种操作如果发生在连接态不提前调整连接参数或设计分时写入基本等于主动断链。把这些数值放进BLE时间尺度里看连接间隔30ms监督超时4s时几十毫秒的阻塞虽然不会立即断链但会造成持续的丢包和重传功耗也会上去监督超时缩到1s以下时单次超过100ms的阻塞就非常危险了。所以我的工程建议是小参数更新几十字节用NVDS或等待空闲窗口一次写入。日志批量写几百字节到几KB用状态机拆写每次写一个字并在两次写入之间穿插BLE事件处理。大块数据更新几十KB以上不要硬在应用层裸写内部Flash优先考虑外部SPI NOR Flash或者专门的OTA/DFU流程。3.4 掉电保护与存储布局设计Flash操作最怕的是写入过程中掉电。页擦除到一半断电这页数据处于不确定状态写入到一半断电数据可能半旧半新。如果产品有掉电保存需求存储布局必须做冗余设计。我常用的存储布局是“双槽 有效标志”区域内容Slot A数据块 CRC32 版本号Slot B数据块 CRC32 版本号Valid Flag记录当前哪个Slot是有效的写入流程把新数据写入当前非活动Slot比如当前有效是A就写B。写完后读回校验确认数据无误。更新Valid Flag指向新的Slot。最后擦除旧Slot留作下次使用。这样即使写入过程中掉电旧Slot依然保留完整数据下次上电时通过Valid Flag和CRC判断哪份数据可用。代价是Flash用量翻倍但可靠性收益很大。另外一个细节我自己调试时经常踩的坑是“写完忘记校验”。Flash写入偶尔会因为电压波动、调试器侵入等原因失败如果不做回读校验等到设备运行起来才发现配置是坏的排查成本会很高。所以VERIFY阶段不能省哪怕只是对关键数据做校验。4. 实测中的常见问题与排查技巧4.1 连接态下擦写导致断链现象设备连接正常一旦触发Flash操作几秒后手机侧提示连接断开。用BLE分析仪抓包断链原因大多是Supervision Timeout。排查思路先确认Flash操作实际耗时。在Flash擦写函数前后用GPIO翻转配合逻辑分析仪测量看阻塞时间真实是多少。抓取设备当前连接参数看连接间隔是否过短、监督超时是否过小。检查Flash操作是不是发生在协议栈事件处理路径上比如某回调函数里。解决方案把Flash操作移到主循环空闲调度器里如果数据量较大按2.3节的方法先调大连接间隔给系统留出余量或者改小擦除页数量分多个周期完成。4.2 广播/扫描业务被Flash操作打乱现象设备处于广播模式手机扫描时设备时有时无或者广播数据更新不及时。原因广播事件同样有严格时间要求如果Flash操作正好占用广播发送时刻广播包会被推迟甚至丢弃。广播间隔较短时比如20ms40ms的页擦除足以让连续好几个广播包全部丢失。实践经验是广播模式下做Flash操作前先确认广播间隔是否足够大。如果广播间隔是100ms单次几十ms的阻塞还可以容忍如果广播间隔很短就需要把Flash操作拆到两次广播事件之间或者降低广播频率换存储窗口。另一个偏方是把广播数据先暂存到RAMFlash操作完成后再重新启动广播并更新数据但这个方法要看业务是否能接受广播暂时中断。4.3 在协议栈事件回调里直接操作Flash现象在连接断开回调、GATT写回调等协议栈事件处理函数里直接调用Flash擦写轻则卡顿、重则死机。原因协议栈事件回调运行在协议栈上下文中回调里耗时过长会阻塞后续协议栈处理。Flash操作在硬件层面阻塞CPU取指等于把协议栈按了暂停键等它恢复时链路层状态已经乱了。正确做法回调里只置标志位比如g_flag_need_save 1然后返回。主循环检测到标志后注册一次Flash操作由调度器执行。这是把互斥问题从架构上解决而不是靠运气。4.4 Flash寿命与频繁写入问题现象设备运行几个月后配置参数写不进去了或者写入后读出来数据不对。原因片内Flash有擦写寿命限制。如果应用层频繁写日志、频繁更新参数很容易在某一个固定存储区域反复擦写导致该区域提前达到寿命上限。典型寿命次数因芯片而异但“10k~100k次”这个量级对某些高频写入场景是不够的。排查和处理用调试器读取Flash操作失败时的错误寄存器确认是不是擦写超时或失败。检查代码里是不是每次数据变化都立即写Flash能否通过RAM缓存、定时批量写入来降低写频率。规划磨损均衡不要固定写同一个页轮流使用多个页避免单个区域集中老化。如果日志数据量很大、写入频繁外部SPI NOR Flash或者小容量EEPROM是更合理的选择。4.5 排查思路速查表症状优先排查项推荐处理连接态Flash操作后断链Flash操作真实耗时、连接监督超时、回调路径移到空闲调度器拆写必要时调大连接间隔广播时扫描不到设备广播间隔、Flash操作与广播事件重叠增大广播间隔广播事件外执行Flash操作回调里操作Flash后死机协议栈事件回调里是否出现耗时操作回调置标志主循环统一处理Flash请求数据写入后读回异常是否有校验、掉电是否发生在写入中增加CRC校验双槽备份掉电前延时保持供电写失败但代码没有报错是否只写不校验、是否忽略错误寄存器VERIFY阶段回读校验检查Flash错误标志再补充一句调试经验不要在设备运行过程中用调试器发起额外的Flash擦写或下载操作。运行时调试器的侵入可能触发Flash控制器状态错乱出现类似“flash download failed”或“cannot access memory”这类错误。调试阶段的烧录和运行时的Flash操作要分开看待前者芯片还没跑BLE协议栈不存在互斥问题后者才是这篇笔记讨论的范畴。最后说一点实际体会花了大半篇幅讲代码和参数计算其实最后真正让我受益的是一种意识在这类单核BLE SoC上Flash操作不是“写个函数调一下就完事”的普通外设操作它自带一个几十毫秒的阻塞窗口会直接影响链路层实时性。无论是用NVDS、状态机调度、连接参数调整还是外挂存储核心思路都是让Flash操作“避让”BLE事件而不是和它抢CPU。我个人现在的做法是能用NVDS绝不用裸Flash必须用裸Flash一定会加双槽备份和CRC校验凡是超过一页的数据写入都会走调度器而不是直接塞在主流程里。如果再有连接不稳定的反馈第一步不是改天线而是先把Flash操作的时序拖出来看一遍。希望这篇笔记对你有用也欢迎按自己的场景调整调度器参数——它本身就是一个很灵活的基础框架。