ESP32 使用遇到的问题集----持续更新

目录

0、参考资料

1、遇到的问题以及解决方法

1.1无法进入烧录模式下载程序

1.2 在linux里下载程序的时候老提示串口权限不足

1.3  LoadProhibited StoreProhibited问题   <禁止加载、禁止存储>

1.4 在编译时出现error: unrecognized command line option '-mfix-esp32-psram-cache-issue' 

1.5 Brownout detector was triggered  断电探测器触发复位

1.6  检测到任务堆栈溢出

1.7 未及时重置开门狗

1.8 OTA升级程序时出现一下error 

1.9 MQTT连接下，断网和与服务器间通信不好，ESP32上报的错误

1.9.1 问题1、发送间隔小于100ms或多个任务同时发送时，会发送下面的现象

1.9.2 问题2、MQTT假性连接，数据实际上一直没有发出去

1.9.3 问题3：cert证书无效

1.9.4 问题4 证书不可信任 

1.10 供电不足 

1.11 连接服务器报错(113)

---

 

0、参考资料

https://blog.csdn.net/qq_27114397/article/details/82288917 

1、遇到的问题以及解决方法

1.1无法进入烧录模式下载程序

因为esp32芯片进入烧写模式的条件是启动时检测boot引脚，因此需要摁着boot键才能下载程序。

出现连接不上spi flash时，出现如下情况:

出现这种情况一般是启动配置的strapping引脚采样电平不符合启动模式，需要调整硬件电路。 

1.2 在linux里下载程序的时候老提示串口权限不足

linux下面串口设备的一般是root权限，因此使用串口需要取得root权限或者修改dev目录下串口的权限。

想 串口支持当前用户，需要把当前用户添加到Group，添加办法

sudo usermode -a -G dialout $USER

1.3  LoadProhibited StoreProhibited问题   <禁止加载、禁止存储>

 当应用程序尝试读取或写入无效的内存位置时,会发生此 CPU 异常。

可能原因:写入/读取的地址可在寄存器转储中的 EXCVADDR 寄存器(途中红色划线)中找到.

1、如果此地址为零,则通常表示应用程序尝试引用 NULL 指针(勿忘对数组成员取地址)；

2、如果此地址接近于零,则通常意味着应用程序尝试访问结构体的成员,但指向该结构的指针为 NULL；

3、如果该地址是别的(垃圾值,不在 0x3fxxxxxx - 0x6xxxxxxx 范围内),则可能意味着用于访问数据的指针未初始化或已损坏。

引用NULL指针(&地址引用错误、野指针....)

上述例子原因在于下面，我free掉了这个扇区的信息，后期又esp_ota_get_running_partition()去获取，结果出错。

esp_partition_t * partition = esp_ota_get_running_partition();
ESP_LOGI(TAG,"current partition info: %s",partition->label);
free(partition);

 

1.4 在编译时出现error: unrecognized command line option '-mfix-esp32-psram-cache-issue' 

原因:这是因为ESP32的某些修订存在一些问题，这些问题会对外部RAM的使用产生影响。而这些内容都记录在ESP32 ECO文档中。

ESP-IDF以下列方式处理提及的错误

ESP32 rev v0-----ESP-IDF没有针对此版本硅片中的错误的解决方法，它不能用于将外部的PSRAM映射到ESP32s 主存储映射中。

ESP32 rev v1-----某些机器指令序列在外部存储器位置上运行时(ESP32 ECo 3.2)上运行时，此芯片版本中的错误会带来微信。

为了解决这个问题，编译ESP-IDF的gcc编译器 扩展了一个标志:-mfix-esp32-psram-cache-issue。

将这个标志传递给命令行上的gcc，编译器可以解决这个问题，并只输出可以安全执行的代码。

出现不认识的错误，是编译工具链的问题。

可以通过在ESP-IDF中，选择CONFIG_SPIRAM_CACHE_WOrKAROUND时，将启动此标志。此时ESP-IDF还采取其他措施确保不使用PSRAM访问和违规指令集的组合。这些措施包括:

在Makefile中除能下图选项，即可不启动此标志。不建议使用。

 

 

1.5 Brownout detector was triggered  断电探测器触发复位

已触发断电探测器。

原因在于:

ESP32的电平低于某个值（这个值是可以设定的），然后触发了断电探测器，断电探测器会使得ESP32重新启动。

解决：换个电源，要不就是ESP32板子设计本身有问题，最终的大招，禁用断电探测器

具体参见https://blog.csdn.net/qq_31232793/article/details/87889368

make menuconfig->component config->ESP32-specific->Hardware brownout detect & reset禁用掉这个选项，将不再检测电平。或者也可在再这个选项的下面选择一个更合适的保护电平。

 

1.6  检测到任务堆栈溢出

最简单的方法就是增大堆栈大小，具体选择什么合适的堆栈大小，我暂时还不会。求各位看客指点。 

1.7 未及时重置开门狗

 当时系统在TWDT溢出时间内从未让出过CPU让IDLE任务得以执行。//应该看看CPU占用率

------任务分析:可以试着关闭一些调试打印(调试打印也需要占用时间)

 

1.8 OTA升级程序时出现一下error 

system_event_sta_disconnected_handle_default 243 esp_wifi_internal_reg_rxcb

 

 

 

 

1.9 MQTT连接下，断网和与服务器间通信不好，ESP32上报的错误

用的IDF版本为v3.2.2，出现qos为0时，出现这种错误上报

1.9.1 问题1、发送间隔小于100ms或多个任务同时发送时，会发送下面的现象

 

直到超时，ping不通后，断开连接。 

1.9.2 问题2、MQTT假性连接，数据实际上一直没有发出去

1.9.3 问题3：cert证书无效

1.9.4 问题4 证书不可信任 

1.10 供电不足 

电压不足，报错可以说还有其他类型。下面就是各种类型报错

 

1.11 连接服务器报错(113)

 1.12 连接阿里云断开后重连失败