TG1WDT_SYS_RST / RTC_SW_SYS_RST 这类复位原因

有很大可能和供电相关,而且你看到的 TG1WDT_SYS_RST / RTC_SW_SYS_RST 这类复位原因,常见就是"电源不稳 → CPU/任务跑飞/卡死 → 看门狗触发"或"电源波动导致某段代码主动调用 esp_restart()(例如检测到异常)"。在供电稳定后现象消失,这个相关性非常强。

下面给你一套从机理 → 证据 → 规避方案的实战排查/改进清单(ESP32-C3 适用)。


1) 这两种复位通常意味着什么

  • TG1WDT_SYS_RST :Timer Group 1 的看门狗触发复位

    常见原因:高负载时某个任务长期得不到调度、临界区太久、禁中断太久、SPI Flash 访问异常卡住、Wi-Fi/BLE 驱动卡住等。供电抖动会放大这些问题(尤其是 Flash/射频瞬态电流导致电压下陷)。

  • RTC_SW_SYS_RST :软件触发系统复位

    典型来源:代码调用 esp_restart() / abort() 导致重启,或者某些组件检测到异常后触发重启。供电异常也可能触发异常路径(例如 NVS/Flash 读写失败、Wi-Fi 启动失败反复重试最后重启)。


2) "临界电压/电流"下为什么会表现成 WDT/软件复位,而不是 Brownout?

因为电源问题不一定是"持续低压",更常见是瞬态压降/纹波/尖峰

  • Wi-Fi 发射瞬间、CPU 提频、Flash 读写瞬间,电流脉冲很大

  • 电源路径阻抗(线太长、DC/DC 响应慢、LDO 余量不足、走线太细、地弹跳)→ 造成 VDD 瞬间下陷

  • 下陷短到没触发 brownout ,但足以让 Flash/QSPI 或总线出现错误、任务卡住、驱动异常,最终 WDT 或软件自恢复重启

所以"换稳定供电就好了"完全符合这个机理。


3) 你该怎么快速确认是不是供电

A. 直接抓波形(最有效)

用示波器在模组 3V3 引脚附近测:

  • 触发条件:跌落到 3.0V/2.9V 附近(你们系统门限不同)

  • 重点看:Wi-Fi启动、连接、发包时是否有明显下陷/振铃

注意:探头接地要短(弹簧地),否则你会看到假的振铃。

B. 软件侧打印更细的复位信息

  • 打印 esp_reset_reason()

  • 打印启动时的 rtc_get_reset_reason()(如果你们有)

  • 开启 WDT 触发时的 backtrace/任务名(如果可用)

C. 人为制造负载验证

  • 提高 Wi-Fi 发包功率/频繁扫描

  • 提高 CPU 频率

  • 连续 Flash 读写

    如果这些动作更容易复位,基本锁定供电/瞬态。


4) 规避方案(工程上最常用、最有效)

方案 1:把"电源瞬态能力"做足(优先级最高)

  1. 就近去耦/储能(贴在模组 3V3 pin 附近)
  • 0.1µF + 1µF(高频去耦)

  • 再加 10µF ~ 47µF(低频/瞬态储能)

  • 如果你现在只有 10µF,建议提升到 22µF/47µF 试试(低 ESR)

  1. 电源芯片选型/余量
  • LDO:确保在峰值电流下仍有足够压差;注意温升会降能力

  • DC/DC:看瞬态响应(load step response),必要时加输出电容/补偿

  1. 降低电源路径阻抗
  • 3V3 走线加宽、缩短

  • 地回路完整、避免细长地线导致地弹跳

  • 如果是线束供电,线束压降非常常见(尤其 500mA 级脉冲)

方案 2:开启/校准 Brownout,让复位更"可控"

  • 如果你现在 brownout 被关闭或门限太低,建议开启 并设置合适门限

    这样电压下陷时会直接 brownout reset,而不是跑飞卡死触发 WDT,现象更可诊断,也更安全。

(门限要结合你们 3V3 最低工作电压与系统余量来定,别设太高导致误复位。)

方案 3:降低峰值电流 & 负载突变

  • Wi-Fi 发射功率适当降低(esp_wifi_set_max_tx_power

  • 避免"Wi-Fi 启动同时大量外设上电/LED 全亮/电机启动"

  • 把耗电动作分散:上电后延迟启动 Wi-Fi,或分阶段初始化

方案 4:软件侧让 WDT 更不容易误杀(但别当根因解决)

  • 检查是否有长时间关中断/长临界区

  • 大循环里加 vTaskDelay(1) 或喂狗点

  • 避免在高负载期间同步阻塞 Flash/IO 太久

  • 如果有 PSRAM/Flash 操作,确保在电源抖动时不会进入死循环重试

但如果根因是供电,软件只能"缓解",不能根治。


5) 建议你先做的 3 个动作(最快出结果)

  1. 在模组 3V3 就近加 47µF + 1µF + 0.1µF(低 ESR)

  2. 示波器抓一次 Wi-Fi 连接/发包时 3V3 波形

  3. 降低 Wi-Fi Tx Power + 上电延迟启动 Wi-Fi(例如延迟 1~2 秒) 做对比实验

只要这三步做完,基本就能判断:是不是瞬态压降导致。


相关推荐
海水冷却4 小时前
2026年实时音视频服务计费模式指南
实时音视频
番茄灭世神2 天前
PN学堂GD32教程第8篇——RTC
实时音视频
runner365.git2 天前
RTC实现VoiceAgent(二)
大模型·webrtc·实时音视频·voiceagent
xuxie993 天前
N18 RTC
单片机·嵌入式硬件·实时音视频
runner365.git3 天前
RTC会议实时翻译系统
实时音视频
runner365.git3 天前
如何使用RTCPilot配置一个集群RTC服务
webrtc·实时音视频·音视频开发
深念Y4 天前
从WebSocket到WebRTC,豆包级实时语音交互背后的技术演进
websocket·网络协议·实时互动·webrtc·语音识别·实时音视频
海水冷却7 天前
2026 主流 RTC SDK 选型参考,7 大维度横向对比
实时音视频·rtc
TEL189246224779 天前
IT6636/IT66362(3进1出 / 2进1出 HDMI 2.1 48Gbps Retiming Switch,内置 MCU)
音视频·实时音视频·视频编解码
天上路人13 天前
A-59F 多功能语音处理模组在本地会议系统扩音啸叫处理中的技术应用与性能分析
人工智能·神经网络·算法·硬件架构·音视频·语音识别·实时音视频