1. 项目背景与问题引入

最近在折腾一个基于低功耗蓝牙（BLE）的传感器节点项目，用的是市面上挺常见的一款国产MCU搭配Nordic的nRF52系列蓝牙芯片。项目本身不复杂，就是周期性地采集点温湿度数据，然后通过BLE广播或者连接后上报给手机App。但就在我以为一切就绪，准备做最后的低功耗优化时，一连串的“神秘代码”把我给整懵了——设备在尝试进入深度睡眠或者进行某些特定操作后，会莫名其妙地断开连接，甚至直接复位，而调试器里最常蹦出来的就是0x13、0x16和0x22这几个十六进制的错误码。

如果你也在BLE低功耗调试的深水里扑腾，特别是当你用的SDK或者协议栈文档对错误码的解释语焉不详时，看到这几个数字估计会和我一样头大。它们不像0x00（成功）或0x05（认证失败）那样有明确的通用定义，更像是协议栈底层在某些特定约束条件被违反时抛出的“内部错误”。经过好几天的抓包、啃代码、反复测试，我终于把这几个“拦路虎”的来龙去脉和解决方法给摸清楚了。这篇文章，我就把自己踩坑、填坑的全过程，以及背后涉及到的BLE协议栈机制和低功耗设计要点，掰开揉碎了分享给你。无论你用的是nRF SDK、TI的SimpleLink，还是其他家的BLE方案，这里面的排查思路和核心原理都是相通的。

2. 错误码探源：0x13, 0x16, 0x22 究竟意味着什么？

首先必须明确一点：0x13、0x16、0x22并非Bluetooth SIG官方核心规范中定义的通用HCI或ATT错误码。像0x01（无效句柄）、0x02（读不被允许）这些，在蓝牙核心规范卷3，F部分，3.4.1节有标准定义。而我们遇到的这几位，通常是特定BLE协议栈实现（尤其是SoftDevice，即Nordic的蓝牙协议栈）内部使用的、表示资源或状态冲突的错误码。它们的含义需要结合具体SDK的源码或文档来解读，但根据我的调试经验和社区常见反馈，可以给出如下映射和解释：

2.1 0x13 - NRF_ERROR_NO_MEM / NRF_ERROR_RESOURCES

这个错误码在很多Nordic SDK的nrf_error.h文件中被定义为NRF_ERROR_NO_MEM（内存不足）或其泛化版本NRF_ERROR_RESOURCES（资源不足）。在BLE上下文中，它极少指简单的堆（heap）内存耗尽，更多时候指的是协议栈内部管理的资源池（Resource Pool）耗尽。

什么是协议栈资源池？你可以把它想象成一个酒店的前台。酒店（协议栈）有固定的房间（资源单元）用来处理各种事务。当一个连接建立时，协议栈需要分配“房间”来存储连接上下文、加密信息、数据包缓冲区等。当应用程序发起一个操作，比如准备发送一个长数据（Write Long Characteristic），协议栈也需要临时“开个房间”来管理这个分片传输的过程。

触发0x13的典型场景：

1. 连接数超限：你的设备可能支持最多8个并发连接，但协议栈内部为每个连接分配的上下文存储池可能只有4个。当尝试建立第5个连接时，即使逻辑上允许，底层资源池也已耗尽，返回0x13。
2. 并发操作过多：在单个连接上，快速、不间断地连续调用sd_ble_gattc_write（客户端写）或sd_ble_gatts_hvx（服务端通知）等函数，且未等待前一个操作完成（即未收到对应BLE_EVT_TX_COMPLETE事件）。每个未完成的数据传输都会占用一个发送缓冲区资源。缓冲区被占满后，新的发送请求就会失败。
3. 低功耗模式下的定时器冲突：为了节能，协议栈会使用低功耗定时器来调度事件（如连接间隔）。当应用层也大量使用相同优先级的软件定时器（app_timer），且在错误的时间点（如在协议栈临界区）尝试创建或启动定时器，可能会因为底层定时器资源不足而间接引发0x13。

2.2 0x16 - NRF_ERROR_INVALID_STATE

这个错误码直译为“无效状态”。它是低功耗调试中最常见、也最狡猾的错误之一。它意味着你要求协议栈执行的某个操作，与协议栈当前所处的内部状态机位置不相容。

协议栈的状态机思维：BLE协议栈（特别是连接层LL和链路层L2CAP）是一个复杂的状态机。例如，一个连接可能处于IDLE（空闲）、CONNECTED（已连接）、ENCRYPTING（加密中）、SLEEP（睡眠）等多种状态。某些操作只在特定状态下是合法的。

触发0x16的典型低功耗相关场景：

1. 在错误的时间点进入/退出低功耗模式：这是重灾区。比如，在协议栈正在处理一个数据包（TX_RX状态）的过程中，或者在等待一个连接事件（CONN_EVT_WAIT状态）的当口，应用程序直接调用sd_app_evt_wait()或类似的进入低功耗函数，强制CPU进入深度睡眠。这会导致协议栈丢失上下文，醒来后状态混乱，后续任何操作都可能返回0x16。
2. 异步操作未完成：你发起了一个断开连接请求（sd_ble_gap_disconnect），但这是一个异步过程。在BLE_GAP_EVT_DISCONNECTED事件还未回调给应用层之前，连接在协议栈内部可能还处于“正在断开”（DISCONNECTING）的中间状态。此时如果你立即尝试重新初始化GATT服务或者释放相关资源，就可能因为状态不符而收到0x16。
3. 服务/特性配置时机不当：在连接建立后的BLE_GAP_EVT_CONNECTED事件中，立即配置客户端特征配置描述符（CCCD）以使能通知。但如果对端设备（中央设备）的MTU交换请求还没处理完，GATT层可能还未就绪，此时写CCCD可能因状态无效而失败。

2.3 0x22 - NRF_ERROR_BUSY / NRF_ERROR_TIMEOUT

这个错误码常表示“忙”或“超时”。它指向了时间窗口的冲突和竞争条件。在低功耗设计中，为了省电，射频（Radio）和高速外设（如SPI、I2C）会频繁开启和关闭，时序变得非常关键。

触发0x22的典型场景：

1. 射频活动冲突：BLE协议栈的工作是围绕“连接事件”（Connection Event）这个时间窗口进行的。在连接事件之外，射频通常是关闭的以省电。如果你在应用层安排了一个耗时很长的操作（比如通过SPI读取一个大型Flash芯片），而这个操作意外地跨越了下一个连接事件的开始时间，协议栈需要开启射频却发现相关硬件（SPI）或总线（DMA）还被占用着，就会产生NRF_ERROR_BUSY，导致连接事件丢失，严重时连接断开。
2. 阻塞式函数调用：在中断服务程序（ISR）或高优先级任务中，调用了可能等待协议栈响应的阻塞式函数（尽管Nordic SDK多以异步事件为主，但某些底层驱动可能有阻塞行为）。这会导致协议栈无法在预期的时间片内处理关键任务，从而引发内部超时（NRF_ERROR_TIMEOUT）。
3. 低功耗外设唤醒延迟：当MCU从深度睡眠（System OFF或STOP模式）被唤醒时，高速时钟（如HFXO）需要时间起振稳定。如果协议栈在唤醒后立即要求进行射频操作，而时钟尚未就绪，也可能导致底层驱动返回“忙”错误。

核心心得：这三个错误码常常不是孤立出现的。一个0x16（无效状态）可能导致后续操作分配资源失败，引发0x13（资源不足）。而由时序问题引发的0x22（忙/超时）又可能把协议栈置于一个未定义状态，从而触发0x16。调试时，需要把它们作为一个关联的症状群来看待。

3. 低功耗场景下的深度调试与问题复现

理论分析之后，我们需要一套方法来稳定地复现问题，并定位到具体的代码行或配置项。对于这类间歇性、与状态和时序强相关的bug，盲目的“printf”大法效率很低。下面是我总结的调试流程。

3.1 工具链准备与关键日志使能

工欲善其事，必先利其器。除了基本的J-Link调试器和IDE（如Segger Embedded Studio, Keil），以下工具和配置至关重要：

1. 协议栈日志（RTT Logging）：确保在SDK的sdk_config.h中，打开最高级别的协议栈调试日志。以nRF5 SDK为例，需要关注：

   #define NRF_LOG_ENABLED 1 #define NRF_LOG_DEFAULT_LEVEL 4 // 或DEBUG级别 #define BLE_GATT_LOG_ENABLED 1 #define BLE_GAP_LOG_ENABLED 1

   这些日志能告诉你协议栈内部发生了什么，比如状态转换、事件分发、资源分配/释放。当错误发生时，查看错误码之前的几条日志，往往能找到线索。

2. 功耗分析仪与电流波形：像Joulescope或Nordic的Power Profiler Kit II这样的工具必不可少。它们能绘制出微安级甚至纳安级的实时电流波形。你需要重点关注：

   • 连接事件期间的电流峰值是否正常、完整？
   • 在预期进入深度睡眠的时段，电流是否真的降到了目标值（如2uA）？还是出现了周期性的“毛刺”或持续的高电流平台？
   • 错误发生时刻的电流波形是否有异常？例如，在应该射频关闭的时间点出现了射频活动。

3. 空中抓包（Sniffer）：使用Ellisys、Frontline或nRF Sniffer这类工具，捕获空中的BLE数据包。这是理解连接交互和诊断断开原因的金标准。当设备断开时，抓包工具能清晰地看到最后一刻交互的报文是什么，是链路层超时（LL Timeout）？还是对端发起的断开（Disconnect Command）？或者是加密失败？这能帮你判断问题是出在本地设备还是对端（手机）。

3.2 构建可复现的测试用例

间歇性问题最难搞。为了复现，你需要简化场景，并施加压力。

1. 单一连接，极限参数：先与一个手机App建立连接。然后，逐步调整连接参数向“压力测试”方向靠拢：

   • 极短的连接间隔（如7.5ms）：这会极大增加协议栈处理事件的频率，容易暴露资源（0x13）和时序（0x22）问题。
   • 极长的从机延迟（Slave Latency，如最大值）：测试协议栈在长时间无通信后，恢复连接事件时的状态机稳定性（易触发0x16）。
   • 最大化MTU（如247字节）：进行大数据量传输，考验发送缓冲区和内存管理。

2. 模拟低功耗唤醒：在代码中，在每次计划进入低功耗前（调用sd_app_evt_wait()或__WFE()），手动触发一个GPIO翻转，并用逻辑分析仪或示波器捕捉这个信号。同时，用另一个通道捕捉表示“射频活动”的信号（如协议栈提供的radio_active事件或特定GPIO）。将这两个信号与电流波形对齐，你就能精确判断：是在射频活动期间尝试睡眠了？还是在睡眠期间被意外唤醒并尝试了射频操作？

3. 制造并发操作：编写测试代码，模拟快速点击App按钮，在极短时间内连续发送多个写请求或使能多个通知。观察协议栈日志，看是否出现“排队”或“拒绝”的日志，以及错误码是否随之而来。

3.3 排查过程中的“望闻问切”

当问题复现后，结合所有日志和波形，按以下顺序排查：

第一步：看抓包，定责任。首先分析空中抓包数据。如果断开是由你的设备（从机）发起的LL层断开请求，那么问题大概率在本地。如果是对端（主机）发起的，或者发生了LL超时，则需要结合本地日志看断开前本地协议栈的状态。抓包能帮你排除50%的对端兼容性问题。

第二步：看电流，定时序。观察错误发生时刻前后的电流波形。理想情况下，一个连接事件应该是一个“脉冲群”。如果波形出现以下异常：

• 脉冲缺失：该有连接事件的时候没有电流脉冲，可能是协议栈因状态错误（0x16）跳过了调度。
• 脉冲变形或拉长：在射频活动期间夹杂了额外的电流消耗，可能是应用层的高功耗外设（如传感器）在错误的时间被启动了（0x22冲突）。
• 睡眠基线抬高：无法进入深度睡眠，可能是某个外设未关闭，或协议栈内部有任务未完成（阻塞导致无法进入idle状态，进而无法睡眠）。

第三步：看日志，追状态。仔细阅读从设备启动到错误发生时的全部RTT日志。搜索关键词如state,alloc,free,schedule,timeout。特别关注错误码出现前，最后一个成功的协议栈操作是什么，以及紧随其后的系统事件是什么。这能帮你还原协议栈状态机的最后几步。

4. 针对0x13（资源不足）的解决方案与设计优化

解决0x13问题的核心思路是：精细化管理协议栈资源，并确保应用层行为与资源容量相匹配。

4.1 调整协议栈资源池配置

这通常需要修改SDK的配置文件或初始化参数。以nRF5 SDK为例，你需要关注softdevice_handler.c或sdk_config.h中的相关定义：

// sdk_config.h 示例 #define NRF_SDH_BLE_GAP_EVENT_LENGTH 6 // GAP事件长度，影响每个连接事件能传输的数据量 #define NRF_SDH_BLE_GATT_MAX_MTU_SIZE 247 // 最大MTU，增大需要更多RAM #define NRF_SDH_BLE_PERIPHERAL_LINK_COUNT 2 // 最大外设角色连接数 #define NRF_SDH_BLE_CENTRAL_LINK_COUNT 0 // 最大中心角色连接数 #define NRF_SDH_BLE_TOTAL_LINK_COUNT 2 // 总连接数 #define NRF_SDH_BLE_VS_UUID_COUNT 1 // 自定义UUID数量 // 发送缓冲区数量，直接影响并发写/通知能力 #define NRF_SDH_BLE_GATTS_ATTR_TAB_SIZE 0x600 // GATT属性表大小 // 更直接的，某些SDK版本有明确的TX/RX缓冲区数量配置 #define NRF_BLE_GATT_ATT_MTU_DEFAULT 23 // 增加ATT_MTU后，可能需要增加数据长度 #define NRF_SDH_BLE_GAP_DATA_LENGTH 251

如何确定合适的值？

1. 连接数：根据产品需求设定，留有余量。
2. MTU和数据长度：如果应用需要传输大量数据，增大MTU和数据长度能提高吞吐，但会显著增加单个连接对RAM的消耗。你需要计算：RAM_used_per_conn ≈ (MTU_Size * N) + Fixed_Overhead。N是缓冲区数量，与并发操作数相关。
3. 缓冲区数量：这是一个权衡。更多的缓冲区允许更高的并发，但占用更多RAM。你可以通过统计在压力测试下，sd_ble_gatts_hvx返回NRF_ERROR_RESOURCES的频率来调整。如果频繁出现，可适当增加。但更好的方法是优化应用逻辑，避免并发。

4.2 应用层流量控制与异步确认

这是解决0x13最有效的软件手段。核心原则：绝不假设发送会立即成功，总是等待前一个传输完成确认后再发起下一个。

错误模式（快速连续发送）：

// 伪代码，错误示范 for(int i=0; i<10; i++) { err_code = sd_ble_gatts_hvx(conn_handle, &hvx_params); // 直接循环发送 if (err_code != NRF_SUCCESS) { // 可能从第3次开始就返回NRF_ERROR_RESOURCES (0x13) NRF_LOG_ERROR("Send failed: 0x%X", err_code); } }

正确模式（基于事件的流控）：

// 1. 定义一个发送状态机和队列 typedef struct { bool is_busy; uint8_t data_queue[QUEUE_SIZE][DATA_LEN]; uint8_t queue_head, queue_tail; } tx_state_t; // 2. 发送函数改为“请求发送”，实际发送由事件触发 static void request_send_data(uint8_t *data) { if (state.is_busy) { // 如果正在发送，则将数据放入队列 enqueue_data(data); return; } // 否则立即开始发送 start_send_data(data); state.is_busy = true; } static void start_send_data(uint8_t *data) { // 填充 hvx_params... err_code = sd_ble_gatts_hvx(conn_handle, &hvx_params); // 注意：这里即使返回成功，也只意味着请求被接受，不代表已发送完成 } // 3. 在 BLE_GATTS_EVT_HVN_TX_COMPLETE 事件处理中，进行后续发送 void ble_evt_handler(ble_evt_t const * p_ble_evt) { switch (p_ble_evt->header.evt_id) { case BLE_GATTS_EVT_HVN_TX_COMPLETE: // 上一个通知/指示发送完成 state.is_busy = false; // 检查队列中是否有等待的数据 if (queue_not_empty()) { uint8_t *next_data = dequeue_data(); start_send_data(next_data); state.is_busy = true; } break; // ... 处理其他事件 } }

通过这种“发送-等待完成-再发送”的机制，你确保了任何时候最多只有一个未完成的传输占用着协议栈的发送缓冲区资源，从根本上避免了0x13。

5. 根治0x16（无效状态）的时序与状态管理

0x16的根源在于代码逻辑没有尊重协议栈的状态机。解决方法的核心是：将你的应用逻辑与协议栈的事件驱动模型深度绑定，在任何可能改变系统状态的操作前，进行状态检查。

5.1 低功耗入口的“安全门”检查

绝对不能在任何地方随意调用进入低功耗的函数。必须建立一个统一的、条件检查的入口点。

static bool is_system_ready_for_sleep(void) { // 检查1: 协议栈是否处于空闲状态？Nordic SoftDevice 提供了 sd_ble_gap_addr_get 等函数可以间接判断， // 但更直接的方法是使用一个由协议栈事件驱动的标志位。 if (!ble_stack_is_idle()) { return false; } // 检查2: 是否有任何应用层的异步操作正在进行？（如Flash写操作、传感器读取） if (app_tx_in_progress || sensor_read_pending) { return false; } // 检查3: 所有高功耗外设（如SPI、I2C、ADC）是否已关闭？ if (spi_busy() || i2c_busy()) { return false; } // 检查4: 软件定时器队列是否为空？或者是否有在睡眠期间必须运行的定时器？ if (app_timer_has_pending_actions()) { return false; } return true; } void enter_low_power_mode(void) { if (!is_system_ready_for_sleep()) { // 如果不满足条件，可以设置一个标志，稍后再尝试，或者进入浅睡眠（WFI） schedule_sleep_retry(10); // 10ms后重试 return; } // 执行进入深度睡眠前的最后准备工作 gpio_power_down_all_unused_pins(); // 关闭所有未使用的GPIO电源 peripheral_power_down(); // 关闭外设时钟和电源域 // 正式进入低功耗等待 uint32_t err_code = sd_app_evt_wait(); if (err_code != NRF_SUCCESS) { // 即使这里出错，也通常是唤醒后的错误，记录日志 NRF_LOG_WARNING("sd_app_evt_wait returned 0x%X", err_code); } // 唤醒后的恢复工作 peripheral_power_up(); // ... 其他初始化 }

这个is_system_ready_for_sleep函数是你的“安全守门员”。ble_stack_is_idle()的实现是关键，你可以通过在协议栈事件处理函数中设置和清除一个标志位来实现。例如，在收到BLE_EVT_TX_COMPLETE、BLE_EVT_USER_MEM_RELEASE等表示一个操作周期完成的事件后，将标志位置为true；在发起任何新的协议栈操作请求前，将其置为false。

5.2 连接生命周期内的状态标志管理

对于连接建立、断开、加密等过程，使用明确的状态标志来防止无效操作。

typedef enum { CONN_STATE_IDLE, CONN_STATE_CONNECTING, CONN_STATE_CONNECTED, CONN_STATE_DISCONNECTING, CONN_STATE_ENCRYPTING, } conn_state_t; static conn_state_t m_conn_state = CONN_STATE_IDLE; void start_disconnection(void) { if (m_conn_state != CONN_STATE_CONNECTED) { NRF_LOG_WARNING("Cannot disconnect, state is %d", m_conn_state); return; } m_conn_state = CONN_STATE_DISCONNECTING; sd_ble_gap_disconnect(m_conn_handle, BLE_HCI_REMOTE_USER_TERMINATED_CONNECTION); } void ble_evt_handler(ble_evt_t const * p_ble_evt) { switch (p_ble_evt->header.evt_id) { case BLE_GAP_EVT_CONNECTED: m_conn_state = CONN_STATE_CONNECTED; // 不要在这里立即进行密集的GATT配置，可以启动一个定时器稍后处理 start_delayed_gatt_config(100); // 100ms后配置 break; case BLE_GAP_EVT_DISCONNECTED: m_conn_state = CONN_STATE_IDLE; // 在状态变为IDLE后，再安全地释放或清理连接相关资源 cleanup_connection_resources(); break; case BLE_GAP_EVT_SEC_PARAMS_REQUEST: m_conn_state = CONN_STATE_ENCRYPTING; break; case BLE_GAP_EVT_AUTH_STATUS: if (p_ble_evt->evt.gap_evt.params.auth_status.auth_status == BLE_GAP_SEC_STATUS_SUCCESS) { m_conn_state = CONN_STATE_CONNECTED; // 加密成功，回到连接状态 } break; } }

通过这种显式的状态管理，你在尝试执行任何操作前（如发送数据、修改服务），都可以先检查m_conn_state，从而避免在“正在断开”或“正在加密”的状态下执行非法操作，从根本上杜绝因状态错误导致的0x16。

6. 规避0x22（忙/超时）的硬件与软件协同设计

0x22错误是硬件资源冲突和软件时序缺陷的综合体现。解决它需要软硬件协同设计。

6.1 外设互斥与时间窗规划

在低功耗BLE设备中，射频（Radio）是最高优先级的硬件资源。必须确保在连接事件窗口（通常是1-2ms的射频活动期）前后，留有足够的“安静时间”。

制定一个明确的时间预算表：

在代码中，你可以利用连接事件回调或定时器来实现这个规划：

static void on_conn_event_begin(void) { // 此函数在连接事件即将开始时被调用（可通过协议栈事件或PPI近似实现） disable_high_speed_peripherals(); // 关闭SPI、I2C等 m_peripheral_busy = true; } static void on_conn_event_end(void) { // 连接事件结束 m_peripheral_busy = false; // 可以在这里启动一个延迟任务，稍后恢复外设操作 start_deferred_sensor_read(5); // 5ms后再读传感器 } bool safe_to_start_spi_transfer(void) { return (!m_peripheral_busy) && (time_until_next_conn_event() > 3); // 距离下个事件大于3ms } void my_spi_read_function(void) { if (!safe_to_start_spi_transfer()) { // 不安全，将任务放入队列，等待安全时间窗 schedule_spi_task_later(); return; } // 安全，执行SPI操作 start_spi_transfer(); }

6.2 中断与优先级配置

错误的中断优先级配置是导致0x22（超时）的隐形杀手。协议栈的射频中断、定时器中断通常需要最高的优先级。

以Cortex-M系列为例的推荐配置：

• SysTick中断：最低优先级（如0xF）。防止系统滴答中断打断关键射频时序。
• 协议栈相关中断（如RADIO, TIMER0, RTC0）：设置为最高或次高优先级（如0x0或0x1）。
• 应用层高优先级任务中断（如GPIO唤醒）：设置为中优先级（如0x5）。
• 应用层普通外设中断（如UART, SPI）：设置为低优先级（如0xA）。

关键检查点：

1. 确保没有在任何中断服务程序（ISR）中调用可能阻塞或等待协议栈响应的函数。
2. 对于耗时超过几十微秒的ISR，考虑将实际处理移到主循环或低优先级任务中，ISR只负责设置标志位。
3. 使用__disable_irq()和__enable_irq()这类临界区保护时要极其小心，确保不会意外屏蔽掉协议栈的关键中断。如果必须使用，时间窗口应控制在极短（如几微秒）内。

6.3 从深度睡眠唤醒的初始化序列

当MCU从深度睡眠（System OFF）唤醒时，时钟和外设需要重新初始化。如果协议栈在初始化完成前就尝试使用射频，会导致0x22。

正确的唤醒后初始化流程：

void wakeup_from_deep_sleep(void) { // 1. 最小化系统初始化（时钟、电源） clocks_init(); // 启动HFXO，等待稳定（重要！） power_management_init(); // 2. **先**重新初始化协议栈依赖的低层驱动和SoftDevice nrf_drv_clock_init(); softdevice_handler_init(...); // 重新初始化SoftDevice // 3. 重新配置协议栈参数（GAP, GATT） ble_stack_init(); gap_params_init(); gatt_init(); // 重新注册事件处理程序 ble_evt_handler_register(); // 4. 恢复连接参数（如果需要快速重连） sd_ble_gap_adv_start(...); // 开始广播 // 5. **最后**再初始化应用层外设（SPI, I2C, Sensor） spi_init(); sensor_init(); // 此时，系统才真正准备好处理协议栈事件和应用任务 }

这个顺序确保了协议栈在应用层可能产生冲突的外设之前，已经获得了对硬件资源的控制权并处于稳定状态。

7. 综合调试案例：一个真实的0x13/0x16/0x22连环坑

最后，分享一个我实际遇到的综合案例，它几乎集齐了这三个错误。

现象：设备在连接状态下，每当我按下按键准备通过SPI读取Flash ID并发送数据时，有大约30%的概率会立刻断开连接，日志依次出现0x22->0x16->0x13。

排查过程：

1. 抓包分析：显示断开是由从设备（我的设备）发起的LL层断开，原因码是0x08（连接超时）。这说明本地协议栈可能错过了多次连接事件。
2. 电流波形分析：发现在按下按键的时刻，本该出现的连接事件电流脉冲消失了，取而代之的是一个持续约5ms的高电流平台（正是SPI读取Flash的典型电流波形）。
3. 日志分析：在错误发生前的日志中看到：

   [APP]: Button pressed, starting SPI transfer... [SPI]: SPI transaction begin (length: 6 bytes). [BLE]: sd_ble_gatts_hvx() called. // 尝试在SPI传输中发送数据？ [BLE]: ERROR 0x22 (NRF_ERROR_BUSY) from sd_ble_gatts_hvx. [BLE]: State inconsistency detected after error. [BLE]: ERROR 0x16 (NRF_ERROR_INVALID_STATE) from internal scheduler. [BLE]: Failed to allocate resource for connection event. [BLE]: ERROR 0x13 (NRF_ERROR_NO_MEM). [BLE]: Terminating connection due to supervision timeout.

根因分析：

1. 0x22的根源：按键中断服务程序（ISR）直接启动了SPI传输。这个传输阻塞了总线（和CPU），时间长达5ms。与此同时，连接事件到来，协议栈需要射频和相关的定时器/DMA资源，但因为SPI总线被占用，底层驱动返回“忙”。
2. 0x16的连锁反应：因为射频活动失败，协议栈内部为这次连接事件准备的状态和上下文没有被正确清理或转换，导致状态机进入了一个未定义或无效的状态。
3. 0x13的最终结果：由于状态错误，协议栈可能尝试重新调度或恢复连接事件，但之前分配的资源（如数据包缓冲区）因错误而未被释放，新的资源分配请求因池子耗尽而失败。

解决方案：

1. 中断瘦身：将SPI传输从ISR移到主循环。按键ISR只设置一个spi_transfer_pending标志。
2. 增加安全检查：在主循环中执行SPI传输前，调用safe_to_start_spi_transfer()函数（如6.1节所述），检查距离下一个连接事件的时间。
3. 优化SPI速度：将SPI时钟从1MHz提升到4MHz（在Flash允许范围内），将6字节的读取时间从~5ms缩短到~1.5ms，减少了与连接事件窗口冲突的概率。
4. 引入任务队列：如果SPI操作被延迟，将待发送的数据先存入一个应用层缓存，等到SPI操作完成且处于安全时间窗时，再调用sd_ble_gatts_hvx发送。

修改后的代码逻辑：

volatile bool button_pressed = false; static uint8_t pending_data_to_send[20]; static bool data_pending = false; void button_isr(void) { button_pressed = true; // 仅设置标志，不做任何耗时操作 } void main_loop(void) { if (button_pressed) { button_pressed = false; if (safe_to_start_spi_transfer()) { read_flash_id_via_spi(); // 读取完成后，如果有数据要发送，立即发送 if (data_pending) { send_pending_data(); data_pending = false; } } else { // 不安全，先读取Flash，数据待发送 read_flash_id_via_spi(); // 将需要发送的数据存入缓存，并设置标志 memcpy(pending_data_to_send, my_data, sizeof(my_data)); data_pending = true; // 主循环会在后续的安全时间窗检查并发送这个数据 } } // 检查是否有缓存的数据等待在安全时间发送 if (data_pending && safe_to_start_spi_transfer() && ble_stack_is_ready_to_send()) { send_pending_data(); data_pending = false; } // ... 其他任务 }

经过这些修改后，0x13、0x16、0x22错误再也没有出现。设备即使在处理外设操作时，也能稳定地维持BLE连接。这个案例深刻地说明，在低功耗BLE开发中，对时序的敬畏和对硬件资源共享的精细管理，是稳定性的基石。它不是简单的API调用，而是一个需要从系统层面进行架构设计的工作。