ESP32-严重错误-崩溃分析系列-01

1. 崩溃堆栈信息

Guru Meditation Error: Core  0 panic'ed (StoreProhibited). Exception was unhandled.
Core 0 register dump:
PC      : 0x40090ad1  PS      : 0x00060130  A0      : 0x80090640  A1      : 0x3ffbbe80  
A2      : 0x3ff00004  A3      : 0x00000000  A4      : 0x3ffbb094  A5      : 0x00000000  
A6      : 0x00000000  A7      : 0x00000000  A8      : 0x00000000  A9      : 0x00000000  
A10     : 0x00000000  A11     : 0x00060123  A12     : 0x00060120  A13     : 0x3f408329  
A14     : 0x3ffc2138  A15     : 0x00060023  SAR     : 0x00000020  EXCCAUSE: 0x0000001d  
EXCVADDR: 0x00000008  LBEG    : 0x4000c2e0  LEND    : 0x4000c2f6  LCOUNT  : 0x00000000  

ELF file SHA256: 75b6d69fc791b5e9

Backtrace: 0x40090ace:0x3ffbbe80 0x4009063d:0x3ffbbea0

I (22620) esp_core_dump_flash: Save core dump to flash...
I (22626) esp_core_dump_common: Found tasks: (17)!
I (22772) esp_core_dump_flash: Core dump has been saved to flash.

为什么会打印这一串信息出来?

紧急处理程序会将 CPU 寄存器和回溯打印到控制台。

并且,仅会打印异常帧中 CPU 寄存器的值,即引发 CPU 异常或者其它严重错误时刻的值。

上面的芯片使用的是ESP32D模块,实际上ESP32 采用两个哈佛结构 Xtensa LX6 CPU 构成双核系统。但是在小米原生SDK上,只开启了single core。

所以上面的堆栈信息打印的就是CPU0的崩溃信息。 

这一串东西该如何解析出来呢,这个是CPU寄存器的信息呢?

2. 崩溃原因定位

LoadProhibited, StoreProhibited 当应用程序尝试读取或写入无效的内存位置时,会发生此类 CPU 异常。此类无效内存地址可以在寄存器转储的 EXCVADDR 中找到。

  • 如果该地址为零,通常意味着应用程序正尝试解引用一个 NULL 指针。
  • 如果该地址接近于零,则通常意味着应用程序尝试访问某个结构体的成员,但是该结构体的指针为 NULL。  
  • 如果该地址是其它非法值(不在 0x3fxxxxxx - 0x6xxxxxxx 的范围内),则可能意味着用于访问数据的指针未初始化或者已经损坏。

此处崩溃中 EXCVADDR: 0x00000008  符合第二种情况。 说明是结构体的指针为NULL。就是空指针崩溃了。

3. 崩溃信息解析

如果你已经安装了esp的编译tool,并且已经加载到path路径下,可以直接执行:

xtensa-esp32-elf-addr2line -pfiaC -e meizu_light.elf 0x40090ace:0x3ffbbe80 0x4009063d:0x3ffbbea0

得出了堆栈详情信息:

0x40090ace: uxListRemove at /home/zy/esp/esp-idf-xiaomi/components/freertos/list.c:214
0x4009063d: prvProcessExpiredTimer at /home/zy/esp/esp-idf-xiaomi/components/freertos/timers.c:495
 (inlined by) prvProcessTimerOrBlockTask at /home/zy/esp/esp-idf-xiaomi/components/freertos/timers.c:571
 (inlined by) prvTimerTask at /home/zy/esp/esp-idf-xiaomi/components/freertos/timers.c:544

4. 源码分析

static void prvTimerTask( void *pvParameters )
{
TickType_t xNextExpireTime;
BaseType_t xListWasEmpty;

	/* Just to avoid compiler warnings. */
	( void ) pvParameters;

	for( ;; )
	{
		/* Query the timers list to see if it contains any timers, and if so,
		obtain the time at which the next timer will expire. */
		xNextExpireTime = prvGetNextExpireTime( &xListWasEmpty );

		/* If a timer has expired, process it.  Otherwise, block this task
		until either a timer does expire, or a command is received. */
		prvProcessTimerOrBlockTask( xNextExpireTime, xListWasEmpty );

		/* Empty the command queue. */
		prvProcessReceivedCommands();
	}
}

prvProcessTimerOrBlockTask( xNextExpireTime, xListWasEmpty );

调用了 prvProcessExpiredTimer( xNextExpireTime, xTimeNow );

调用了 ( void ) uxListRemove( &( pxTimer->xTimerListItem ) );

调用了 pxItemToRemove->pxNext->pxPrevious = pxItemToRemove->pxPrevious;

定位到此处,应该就是 pxItemToRemove->pxNext 为空指针,而去调用一个空指针的成员变量时,就会出现空指针崩溃问题。

接着去自己业务代码里面查看 timer定时器相关的代码。

5.业务代码自查

static void cancel_long_block_timer() {
  if (long_block_timer != NULL) {
    xTimerStop(long_block_timer, 0);
    long_block_timer = NULL;
    MZ_WARN(TAG, "stop block check");
  }
}

发现了在频繁的创建timer,删除timer。最值得怀疑的地方。 最后改成只创建一次timer。在不需要的地方stop timer即可。满足业务需求。

<think>嗯,用户想了解ESP-01S模块发热导致不正常工作的原因和解决办法。首先,我需要回忆一下之前提供的引用内容。引用[1]提到ESP-01S使用的是3.3V电源,如果接错LM1117的管脚会导致严重发热甚至烧毁。用户可能遇到了类似的问题,比如电源模块接线错误,或者电压不稳。 接着,引用[2]和[3]提到ESP32芯片发热和IO失效的情况,可能涉及电压过高或设计缺陷。虽然ESP-01S和ESP32不同,但可能有共通点,比如电源问题或电路设计不当。 首先,电源问题应该是主要原因。ESP-01S需要稳定的3.3V,如果使用5V直接供电,或者LM1117接错导致电压不稳,都会发热。另外,电流不足也可能导致模块工作异常,比如电源模块输出电流不够,或者线路阻抗太大。 然后,检查电路连接是否正确,特别是LM1117的接线是否正确,输入输出是否反接。引用[1]提到接错会发热严重,所以用户需要确认焊接是否正确。 另外,模块本身的质量问题也有可能,比如引用[3]提到后期淘宝的ESP32CAM发热严重,可能元件老化或散热设计不好。不过ESP-01S是否有类似情况?需要建议用户检查模块批次或更换模块测试。 还有,外部负载过大可能导致电流过载,比如连接的传感器或其他外设耗电太大,超出模块的供电能力,导致发热。建议断开外设测试。 软件方面,固件问题或配置错误可能导致模块持续高负荷运行,比如WiFi频繁连接断开,或者传输数据量过大,导致芯片过热。更新固件或调整软件设置可能有帮助。 解决方案方面,首先要排除电源问题,确保电压稳定在3.3V,电流足够,检查LM1117接线。然后优化散热,比如加散热片或改善通风。检查外部负载,减少不必要的功耗。最后,考虑更换模块或联系厂家技术支持。 用户可能需要一步步排查,从电源开始,再检查电路连接,最后考虑模块本身的问题。需要提醒用户注意安全,避免烫伤或损坏其他部件。</think>### ESP-01S模块发热及异常工作原因分析 #### 一、发热主要原因 1. **电源问题** - ESP-01S要求3.3V供电,若直接使用5V输入或电压不稳定,会导致芯片过载发热[^1]。 - 电源转换器件(如LM1117T-3.3V)接线错误时,输出电压异常或自身发热严重,间接影响模块稳定性。 2. **电流不足** - 当WiFi模块处于高负载状态(如数据传输)时,瞬时电流可达300mA以上。若电源模块输出电流不足(如<500mA),可能导致电压骤降和芯片发热。 3. **硬件设计缺陷** - PCB走线过细或供电回路阻抗过大,导致压降和局部发热[^2]。 - 未按规范添加滤波电容(如10μF+0.1μF组合),电源噪声引发芯片异常功耗。 #### 二、异常工作表现 1. WiFi频繁断连或无法连接 2. 串口通信失效 3. 固件崩溃(需硬件复位) 4. 部分GPIO功能异常[^3] #### 三、解决方案 1. **电源优化** - 严格检查LM1117接线(输入5V→VIN,输出3.3V→VOUT),建议使用数字万用表验证输出电压[^1]。 - 更换更高性能的DC-DC模块(如TPS63060),支持800mA连续输出。 ```python # 示例:通过ADC监控电压(需硬件支持) import machine adc = machine.ADC(machine.Pin(34)) voltage = adc.read() * 3.3 / 4095 # ESP32 ADC读数转电压 ``` 2. **硬件改进** - 在模块VCC-GND间并联220μF电解电容+0.1μF陶瓷电容 - 增加PCB覆铜面积,降低回路阻抗 - 使用独立电源层(四层板设计最佳) 3. **散热处理** - 贴装铝制散热片(尺寸≥10mm×10mm) - 控制环境温度(建议<40℃),避免密闭空间使用 4. **软件优化** - 启用Deep-sleep模式降低功耗: ```c // ESP-IDF示例代码 esp_deep_sleep(1000000 * sleep_seconds); ``` - 设置WiFi传输功率:`esp_wifi_set_max_tx_power(8)`(单位0.25dBm) #### 四、诊断流程 1. 断开所有外设,单独测试ESP-01S 2. 监测工作电流(正常范围:空闲80mA,峰值350mA) 3. 使用热成像仪定位热点(芯片/电源/天线区域) 4. 刷写官方AT固件排除软件问题
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

专注和坚持是最好的导师

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值