异常复位排查思路

第一步先把“硬件问题”和“应用问题”分开。直接烧一个最小hello_world不要带 Wi-Fi、BLE、USB 自定义、外设初始化也不要高频日志。如果最小例程稳定基本就不是 flash/供电/芯片本体优先级最高的问题而是你当前应用初始化流程里某段代码触发了 WDT。如果最小例程也反复出现TG0_WDT_HPSYS再优先看供电、flash 参数、USB 下载链路、芯片/模组本身。ESP-IDF 也建议先用最小工程验证启动链路。第二步先盯“打印太多/死循环打印”。因为 PC 停在_svfiprintf_r最值得先查while(1)里连续ESP_LOGI/printf没有vTaskDelay()早期初始化阶段反复打印ISR、回调、临界区里打印打印超大 JSON / hex dump / 长字符串Espressif 的看门狗示例里就专门举了“无限循环打印导致 task watchdog”的例子。第三步把日志输出先切到更稳定的方式做对比。如果你现在用的是 C5 的 USB Serial/JTAG 做控制台建议临时改成 UART0 日志或者至少关掉次级输出只保留一个 console 通道。因为官方文档明确提到USB Serial/JTAG 有内部小缓冲当主机没及时取数据时芯片会等待一次另外如果应用改了 USB 相关引脚/外设串口还会直接消失。这个阶段的目标不是长期方案而是先确认“是不是 USB 日志链路把问题放大了”。第四步检查有没有这些典型 WDT 写法。重点搜你工程里这些位置while (1)/for (;;)没有vTaskDelay()长时间portENTER_CRITICAL()关中断后做复杂逻辑ISR 里打印、malloc、网络调用初始化里等待某个标志位结果一直不退出死等串口、SPI、I2C、网络返回这些都符合 Espressif 对 interrupt watchdog / task watchdog 的典型触发描述。第五步把启动阶段的日志量压到最低。先做这几个动作bootloader log level 调低app log level 临时降到WARN或ERROR注释掉循环打印注释掉大块 dump如果这样就不复位了方向基本就坐实在“日志/阻塞/调度饥饿”这条线上。Bootloader 和 console 输出级别都是官方支持的标准配置项。第六步如果还是复位再看供电和 flash。虽然这份日志里没有直接出现 brownout 文本但如果芯片在启动时电源抖动、外围拉扯仍可能诱发各种异常执行最后表现成 WDT。Espressif 在异常说明里也提到供电瞬态不足会造成启动异常在烧录/启动排障页里则建议把复位电路、下载模式、flash 参数一起核对。你现在最该优先做的是这 4 个动作烧hello_world看还会不会出TG0_WDT_HPSYS把所有高频ESP_LOGx/printf先砍掉 90%搜工程里所有死循环确认都有vTaskDelay()或阻塞等待临时把 console 改到 UART0再复现一次如果你愿意我下一步可以直接按这个日志给你整理一份“ESP32-C5 启动即 WDT 复位最小排查清单”做成你能直接发给硬件和软件同事的版本。