1. 问题现象
在青风 nRF52840 开发板上运行一个纯蓝牙模板工程 （未包含任何 I2C 或传感器代码），当硬件上连接 MPU6050 模块时，系统启动时串口日志在输出前 5 条初始化信息后出现约 2 分钟的长时间停顿，之后才继续输出并正常广播。
拔掉 MPU6050 后，启动恢复正常，日志连续输出无停顿。
2. 排查过程
-
初步怀疑协议栈初始化耗时 ：通过增加日志定位，卡顿点位于
ble_stack_init()内部（log4后无log5输出）。 -
硬件隔离测试：拔掉 MPU6050 后启动正常，插回则重现卡顿，确认问题与 MPU6050 硬件相关。
-
对比测试：另一个无蓝牙协议栈的程序（主动使用 MPU6050 并打印数据）运行流畅，说明 MPU6050 硬件本身并无故障，能正常通信。
-
深入分析：虽然模板工程未初始化 I2C，但 SoftDevice 初始化过程中会进行底层硬件配置，可能短暂检测或配置与 I2C 复用的引脚。此时若 MPU6050 上电瞬间不稳定（如内部复位延迟、引脚为低电平），会导致 I2C 总线被拉低；而 SoftDevice 内部相关驱动未配置超时，进入无限等待；再加上协议栈启用的低功耗模式可能使等待时间进一步延长，最终表现为分钟级卡顿。
3. 根本原因
软件初始化时序与硬件状态的"相遇"问题：
-
MPU6050 本身硬件正常，但在有蓝牙协议栈的程序中，
ble_stack_init()执行时机较早，此时 MPU6050 可能尚未完全稳定，其 SDA/SCL 引脚短暂拉低总线。 -
SoftDevice 内部的底层操作使用了无超时或超时极长的阻塞等待，一旦总线被拉低，便陷入无限等待。
-
协议栈的低功耗模式加剧了等待时间的不可控性。
而在无蓝牙程序中，I2C 初始化晚于系统稳定，且驱动可能设置了超时，因此不会卡顿。
4. 解决方案
在不修改硬件的前提下，通过软件防御解决：
-
在
ble_stack_init()之前主动初始化 TWI 驱动并设置合理超时（如 200ms），即使总线异常也能快速返回错误，避免 SoftDevice 内部无限等待。 -
初始化 TWI 期间临时禁用低功耗 （
sd_power_mode_set(NRF_POWER_MODE_CONSTLAT)），防止睡眠干扰时序。 -
代码示例（以 nrfx_twim 驱动为例）：
5. 经验与教训
-
硬件正常不代表时序兼容：即使外设本身功能完好，其上电/复位时序与软件初始化顺序的微小不匹配也可能导致系统异常。
-
协议栈的"黑盒"操作需警惕：SoftDevice 内部会执行大量底层硬件配置，开发者应预见到这些操作可能对外设引脚产生影响。
-
主动初始化与超时配置是良好防御：即使应用不直接使用某个外设，提前初始化并设置超时可以避免底层驱动因外部异常而永久阻塞。
-
低功耗管理需与关键操作协同：在对时序敏感的外设初始化期间，临时禁用低功耗能有效防止睡眠干扰。
6. 结语
本次 bug 虽然表象是"协议栈初始化慢"，实则源于 MPU6050 与 SoftDevice 初始化时序的冲突，通过主动配置 I2C 驱动超时和临时禁用低功耗，以极小代价解决了问题，提升了系统的鲁棒性。该案例再次证明，嵌入式开发中软硬件协同设计的重要性------即使硬件本身正常，也要充分考虑其与软件初始化流程的时序配合，并对外设异常做好容错处理。
