Zephyr RTOS调试与测试基础：代码覆盖率分析从一次诡异的死机说起去年做的一个工业网关项目，Zephyr跑在STM32MP157上，双核异构，A7跑Linux，M4跑Zephyr负责实时控制。设备在客户现场运行了三天，突然死机——不是看门狗复位，是彻底挂死。串口最后一条日志是“MQTT publish OK”，然后就没了。我翻了两天代码，加了一堆LOG_INF，怀疑是内存泄漏、任务优先级反转、中断嵌套……最后发现，问题出在一个从未被测试覆盖到的分支里：当MQTT broker返回特定错误码时，代码会进入一个死循环等待信号量，而那个信号量永远不会被释放。这个分支在单元测试里压根没跑到，因为测试用例只构造了“正常”和“超时”两种情况。从那以后，我养成了一个习惯：没有覆盖率数据的测试，等于没测。今天聊聊Zephyr里怎么做代码覆盖率分析，以及那些容易踩的坑。工具链选择：GCOV还是LCOV？Zephyr官方推荐用GCOV+LCOV的组合。GCOV是GCC自带的覆盖率工具，LCOV是它的图形化前端。别想着用别的——在嵌入式交叉编译环境下，GCOV是最省心的选择。配置方法很简单，在prj.conf里加两行：CONFIG_COVERAGE=y CONFIG_COVERAGE_GCOV Zephyr RTOS调试与测试基础：代码覆盖率分析从一次诡异的死机说起去年做的一个工业网关项目，Zephyr跑在STM32MP157上，双核异构，A7跑Linux，M4跑Zephyr负责实时控制。设备在客户现场运行了三天，突然死机——不是看门狗复位，是彻底挂死。串口最后一条日志是“MQTT publish OK”，然后就没了。我翻了两天代码，加了一堆LOG_INF，怀疑是内存泄漏、任务优先级反转、中断嵌套……最后发现，问题出在一个从未被测试覆盖到的分支里：当MQTT broker返回特定错误码时，代码会进入一个死循环等待信号量，而那个信号量永远不会被释放。这个分支在单元测试里压根没跑到，因为测试用例只构造了“正常”和“超时”两种情况。从那以后，我养成了一个习惯：没有覆盖率数据的测试，等于没测。今天聊聊Zephyr里怎么做代码覆盖率分析，以及那些容易踩的坑。工具链选择：GCOV还是LCOV？Zephyr官方推荐用GCOV+LCOV的组合。GCOV是GCC自带的覆盖率工具，LCOV是它的图形化前端。别想着用别的——在嵌入式交叉编译环境下，GCOV是最省心的选择。配置方法很简单，在prj.conf里加两行：CONFIG_COVERAGE=y CONFIG_COVERAGE_GCOV 
