Zephyr 日志与追踪实战3 行 Kconfig 搭出全链路调试通道【免费下载链接】zephyrPrimary Git Repository for the Zephyr Project. Zephyr is a new generation, scalable, optimized, secure RTOS for multiple hardware architectures.项目地址: https://gitcode.com/GitHub_Trending/ze/zephyr设备在野外出故障又够不着串口时你靠的就是固件留下的日志与追踪记录。Zephyr 的 logging 子系统只做三件事非阻塞地采集日志、按模块过滤级别、可替换输出后端且都支持运行时重配。本文从 Kconfig 到 log_filter_set 接口把这条链路搭完整日志不够用时再上 tracing。先看懂管道为什么 LOG 宏不会卡住你的业务线程printk 和 logging 子系统最大的区别在于谁等 UART。printk 是同步发送调用者当场完成格式化与输出控制台若为轮询模式调用者会实打实地等在那里中断上下文里要格外小心。而 Zephyr 的日志宏在 deferred 模式默认下只做一件事把带时间戳和模块 ID 的紧凑结构体塞进内部环形缓冲区就返回真正的格式化和后端发送交给一条专门的日志处理线程完成。代码侧你只需要在文件顶部写一行LOG_MODULE_REGISTER(模块名)之后LOG_INF/LOG_WRN/LOG_ERR/LOG_DBG这套宏就能用模块名就是后续过滤的句柄。先把最小闭环的配置写出来CONFIG_LOGy CONFIG_LOG_DEFAULT_LEVEL3 # 0OFF 1ERR 2WRN 3INF 4DBG CONFIG_LOG_BUFFER_SIZE2048 # 内部环形缓冲区大小 CONFIG_LOG_PROCESS_THREADy # 专门线程负责格式化与发送 CONFIG_LOG_PROCESS_TRIGGER_THRESHOLD10 # 攒够 10 条唤醒处理线程这份配置完成了采集进缓冲区 → 处理线程 → 后端的完整管道。缓冲区写满时默认丢弃最旧的消息LOG_MODE_OVERFLOW线程上下文下也可配置为等待固定时间LOG_BLOCK_IN_THREAD保证日志链路不会反过来死锁业务。这套调度的核心逻辑在日志核心实现里。 按场景选输出去处4 类后端后端决定日志落到哪里。Zephyr 把每个后端做成独立的 Kconfig 选项可自由组合完整清单见后端选项列表。实战中用得最多的是四个UART台架调试首选串口号常见 115200直接看流RTT复用 J-Link 的 RTT 通道不占额外串口也不干扰控制台FS日志写进文件系统的文件掉电后依然可以事后取证BLE没有调试接口的现场设备唯一出路走蓝牙 GATT 通道把日志发回来。CONFIG_LOGy CONFIG_LOG_BACKEND_UARTy # 台架串口 # CONFIG_LOG_BACKEND_RTTy # 用 J-Link 的选这个 # CONFIG_LOG_BACKEND_FSy # 落盘归档 # CONFIG_LOG_BACKEND_BLEy # 现场设备这几个选项彼此独立完全可以同时打开 UART FS实现随手可看 落盘归档双通道。像 Meerkat 96 这类部署到现场、串口彻底够不着的开发板切到 BLE 后端只需一行。把噪音关小日志级别的两层过滤编译期3 个数值 按模块自动生成的选项级别是 0~4 的刻度OFF / ERROR / WARNING / INFO / DEBUG。控制全局形状的是三个选项CONFIG_LOG_DEFAULT_LEVEL2 # 未单独声明的模块用这个级别 CONFIG_LOG_MAX_LEVEL4 # 天花板发布版可设为 2 编译期砍掉 INF/DBG CONFIG_LOG_MAIN_LEVEL4 # 每个 LOG_MODULE_REGISTER 都会生成对应模块选项这里有个坑模块自己的级别和LOG_MAX_LEVEL取更严格的那个。发布版瘦身先降LOG_MAX_LEVEL二进制体积才是实打实地变小而不是只少了输出。运行时log_filter_set 随时切换模块级别打开CONFIG_LOG_RUNTIME_FILTERING之后调级别不用重新编译。logger 示例里的写法可以直接抄/* 关掉 temp_sensor 模块的日志 */ log_filter_set(NULL, 0, log_source_id_get(temp_sensor), LOG_LEVEL_NONE);四个参数依次是上下文、域、模块 ID、目标级别。传LOG_LEVEL_NONE是彻底闭嘴传LOG_LEVEL_WRN就只留警告。排查时把嫌疑模块单独提到 DEBUG其他模块保持静音日志流立刻干净。⏱ 日志不够用时用 tracing 抓对象时间线日志回答发生了什么tracing 回答哪个线程、哪个对象、等了多久。打开CONFIG_TRACING后内核对象操作点线程切换、信号量、工作队列、定时器……默认全部打点。格式二选一CTF 是开放格式可丢给 Trace Compass 解析Segger SystemView 给可视化时间线。CONFIG_TRACINGy CONFIG_TRACING_CTFy # 开放格式 CONFIG_TRACING_ASYNCy # 先入环形缓冲再外发开销小 CONFIG_TRACING_BUFFER_SIZE4096 CONFIG_TRACING_BACKEND_UARTy CONFIG_TRACING_SHELLy # 提供 tracing shell 命令异步模式下事件先打包进环形缓冲区由专门的 tracing 线程慢慢外发业务代码只付几个周期的开销。配上TRACING_SHELL运行时进 shell 就能控制开停和查看丢包统计——问题复现当天打开、抓 10 秒、关掉就是最省事的现场取证节奏。更多实现细节看追踪核心实现。典型验证对象是 nRF52840 这类 Cortex-M 开发板SystemView 的时间线把线程切换、中断嵌套直接铺在眼前锁等待这种日志里只能靠文字描述的问题变成了看得见的一段间隔。崩溃取证死机前先把缓冲区倒干净deferred 模式的代价是系统死掉那一刻缓冲区里可能还压着没发出去的消息。两个动作关键动作前把缓冲区排空示例里就有现成模式static void wait_on_log_flushed(void) { while (log_buffered_cnt()) { k_sleep(K_MSEC(5)); } }在sys_reboot或预期崩溃点前调用它或者直接用LOG_PANIC它会先把所有缓冲日志一次性刷出再触发 panic。第二个动作是让 trace 留在内存里tracing 的 RAM 后端TRACING_BACKEND_RAM配RAM_TRACING_BUFFER_SIZE把数据停驻在 RAM 中设备重启后照样能用 GDB 把这段记录倒出来。日志是文字trace 是时间线两条一起上突然死机基本都能翻案。非阻塞采集、分层过滤、可换后端——日志与追踪把死机从悬案变成可回放的档案。你的项目里现场救过命的是哪个后端【免费下载链接】zephyrPrimary Git Repository for the Zephyr Project. Zephyr is a new generation, scalable, optimized, secure RTOS for multiple hardware architectures.项目地址: https://gitcode.com/GitHub_Trending/ze/zephyr创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Zephyr 日志与追踪实战3 行 Kconfig 搭出全链路调试通道【免费下载链接】zephyrPrimary Git Repository for the Zephyr Project. Zephyr is a new generation, scalable, optimized, secure RTOS for multiple hardware architectures.项目地址: https://gitcode.com/GitHub_Trending/ze/zephyr设备在野外出故障又够不着串口时你靠的就是固件留下的日志与追踪记录。Zephyr 的 logging 子系统只做三件事非阻塞地采集日志、按模块过滤级别、可替换输出后端且都支持运行时重配。本文从 Kconfig 到 log_filter_set 接口把这条链路搭完整日志不够用时再上 tracing。先看懂管道为什么 LOG 宏不会卡住你的业务线程printk 和 logging 子系统最大的区别在于谁等 UART。printk 是同步发送调用者当场完成格式化与输出控制台若为轮询模式调用者会实打实地等在那里中断上下文里要格外小心。而 Zephyr 的日志宏在 deferred 模式默认下只做一件事把带时间戳和模块 ID 的紧凑结构体塞进内部环形缓冲区就返回真正的格式化和后端发送交给一条专门的日志处理线程完成。代码侧你只需要在文件顶部写一行LOG_MODULE_REGISTER(模块名)之后LOG_INF/LOG_WRN/LOG_ERR/LOG_DBG这套宏就能用模块名就是后续过滤的句柄。先把最小闭环的配置写出来CONFIG_LOGy CONFIG_LOG_DEFAULT_LEVEL3 # 0OFF 1ERR 2WRN 3INF 4DBG CONFIG_LOG_BUFFER_SIZE2048 # 内部环形缓冲区大小 CONFIG_LOG_PROCESS_THREADy # 专门线程负责格式化与发送 CONFIG_LOG_PROCESS_TRIGGER_THRESHOLD10 # 攒够 10 条唤醒处理线程这份配置完成了采集进缓冲区 → 处理线程 → 后端的完整管道。缓冲区写满时默认丢弃最旧的消息LOG_MODE_OVERFLOW线程上下文下也可配置为等待固定时间LOG_BLOCK_IN_THREAD保证日志链路不会反过来死锁业务。这套调度的核心逻辑在日志核心实现里。 按场景选输出去处4 类后端后端决定日志落到哪里。Zephyr 把每个后端做成独立的 Kconfig 选项可自由组合完整清单见后端选项列表。实战中用得最多的是四个UART台架调试首选串口号常见 115200直接看流RTT复用 J-Link 的 RTT 通道不占额外串口也不干扰控制台FS日志写进文件系统的文件掉电后依然可以事后取证BLE没有调试接口的现场设备唯一出路走蓝牙 GATT 通道把日志发回来。CONFIG_LOGy CONFIG_LOG_BACKEND_UARTy # 台架串口 # CONFIG_LOG_BACKEND_RTTy # 用 J-Link 的选这个 # CONFIG_LOG_BACKEND_FSy # 落盘归档 # CONFIG_LOG_BACKEND_BLEy # 现场设备这几个选项彼此独立完全可以同时打开 UART FS实现随手可看 落盘归档双通道。像 Meerkat 96 这类部署到现场、串口彻底够不着的开发板切到 BLE 后端只需一行。把噪音关小日志级别的两层过滤编译期3 个数值 按模块自动生成的选项级别是 0~4 的刻度OFF / ERROR / WARNING / INFO / DEBUG。控制全局形状的是三个选项CONFIG_LOG_DEFAULT_LEVEL2 # 未单独声明的模块用这个级别 CONFIG_LOG_MAX_LEVEL4 # 天花板发布版可设为 2 编译期砍掉 INF/DBG CONFIG_LOG_MAIN_LEVEL4 # 每个 LOG_MODULE_REGISTER 都会生成对应模块选项这里有个坑模块自己的级别和LOG_MAX_LEVEL取更严格的那个。发布版瘦身先降LOG_MAX_LEVEL二进制体积才是实打实地变小而不是只少了输出。运行时log_filter_set 随时切换模块级别打开CONFIG_LOG_RUNTIME_FILTERING之后调级别不用重新编译。logger 示例里的写法可以直接抄/* 关掉 temp_sensor 模块的日志 */ log_filter_set(NULL, 0, log_source_id_get(temp_sensor), LOG_LEVEL_NONE);四个参数依次是上下文、域、模块 ID、目标级别。传LOG_LEVEL_NONE是彻底闭嘴传LOG_LEVEL_WRN就只留警告。排查时把嫌疑模块单独提到 DEBUG其他模块保持静音日志流立刻干净。⏱ 日志不够用时用 tracing 抓对象时间线日志回答发生了什么tracing 回答哪个线程、哪个对象、等了多久。打开CONFIG_TRACING后内核对象操作点线程切换、信号量、工作队列、定时器……默认全部打点。格式二选一CTF 是开放格式可丢给 Trace Compass 解析Segger SystemView 给可视化时间线。CONFIG_TRACINGy CONFIG_TRACING_CTFy # 开放格式 CONFIG_TRACING_ASYNCy # 先入环形缓冲再外发开销小 CONFIG_TRACING_BUFFER_SIZE4096 CONFIG_TRACING_BACKEND_UARTy CONFIG_TRACING_SHELLy # 提供 tracing shell 命令异步模式下事件先打包进环形缓冲区由专门的 tracing 线程慢慢外发业务代码只付几个周期的开销。配上TRACING_SHELL运行时进 shell 就能控制开停和查看丢包统计——问题复现当天打开、抓 10 秒、关掉就是最省事的现场取证节奏。更多实现细节看追踪核心实现。典型验证对象是 nRF52840 这类 Cortex-M 开发板SystemView 的时间线把线程切换、中断嵌套直接铺在眼前锁等待这种日志里只能靠文字描述的问题变成了看得见的一段间隔。崩溃取证死机前先把缓冲区倒干净deferred 模式的代价是系统死掉那一刻缓冲区里可能还压着没发出去的消息。两个动作关键动作前把缓冲区排空示例里就有现成模式static void wait_on_log_flushed(void) { while (log_buffered_cnt()) { k_sleep(K_MSEC(5)); } }在sys_reboot或预期崩溃点前调用它或者直接用LOG_PANIC它会先把所有缓冲日志一次性刷出再触发 panic。第二个动作是让 trace 留在内存里tracing 的 RAM 后端TRACING_BACKEND_RAM配RAM_TRACING_BUFFER_SIZE把数据停驻在 RAM 中设备重启后照样能用 GDB 把这段记录倒出来。日志是文字trace 是时间线两条一起上突然死机基本都能翻案。非阻塞采集、分层过滤、可换后端——日志与追踪把死机从悬案变成可回放的档案。你的项目里现场救过命的是哪个后端【免费下载链接】zephyrPrimary Git Repository for the Zephyr Project. Zephyr is a new generation, scalable, optimized, secure RTOS for multiple hardware architectures.项目地址: https://gitcode.com/GitHub_Trending/ze/zephyr创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
