第一步：先把“硬件问题”和“应用问题”分开。
直接烧一个最小 hello_world，不要带 Wi-Fi、BLE、USB 自定义、外设初始化，也不要高频日志。

• 如果最小例程稳定，基本就不是 flash/供电/芯片本体优先级最高的问题，而是你当前应用初始化流程里某段代码触发了 WDT。
• 如果最小例程也反复出现 TG0_WDT_HPSYS，再优先看供电、flash 参数、USB 下载链路、芯片/模组本身。ESP-IDF 也建议先用最小工程验证启动链路。

第二步：先盯“打印太多/死循环打印”。
因为 PC 停在 _svfiprintf_r，最值得先查：

1. while(1) 里连续 ESP_LOGI/printf，没有 vTaskDelay()
2. 早期初始化阶段反复打印
3. ISR、回调、临界区里打印
4. 打印超大 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 个动作：

1. 烧 hello_world，看还会不会出 TG0_WDT_HPSYS
2. 把所有高频 ESP_LOGx/printf 先砍掉 90%
3. 搜工程里所有死循环，确认都有 vTaskDelay() 或阻塞等待
4. 临时把 console 改到 UART0，再复现一次

如果你愿意，我下一步可以直接按这个日志给你整理一份 “ESP32-C5 启动即 WDT 复位最小排查清单”，做成你能直接发给硬件和软件同事的版本。