ESP32 stops working for no apparent reason in field
Posted: Thu Jun 20, 2019 9:12 am
Hi,
I am using ESP32 Wroom in a product. After a month of operation the devices stops working. We find that the device does not boot. If I try to flash ESP32, I am getting the error following. The devices were purchased from a reputed online vendor.
esptool.py v2.3.1
Connecting........_____....._____....._____....._____....._____....._____....._____....._____....._____....._____
A fatal error occurred: Failed to connect to ESP32: Timed out waiting for packet header
I am flashing from Command prompt with following command.
C:\Project\SLC>"C:\Project\SLC"\esptool.exe --chip esp32 --port com27 --baud 921600 --before default_reset --after hard_reset write_flash -z --flash_mode dio --flash_freq 80m --flash_size detect 0xe000 "C:\Project\SLC"\boot_app0.bin 0x1000 "C:\Project\SLC"\bootloader_qio_80m.bin 0x10000 "C:\Project\SLC"\controller.ino.bin 0x8000 "C:\Project\SLC"\controller.ino.partitions.bin
Replacing ESP32 fixes the problem. I believe its a reliability issue with ESP32, has anybody faced such reliability issues with ESP32 Wroom?
I am using ESP32 Wroom in a product. After a month of operation the devices stops working. We find that the device does not boot. If I try to flash ESP32, I am getting the error following. The devices were purchased from a reputed online vendor.
esptool.py v2.3.1
Connecting........_____....._____....._____....._____....._____....._____....._____....._____....._____....._____
A fatal error occurred: Failed to connect to ESP32: Timed out waiting for packet header
I am flashing from Command prompt with following command.
C:\Project\SLC>"C:\Project\SLC"\esptool.exe --chip esp32 --port com27 --baud 921600 --before default_reset --after hard_reset write_flash -z --flash_mode dio --flash_freq 80m --flash_size detect 0xe000 "C:\Project\SLC"\boot_app0.bin 0x1000 "C:\Project\SLC"\bootloader_qio_80m.bin 0x10000 "C:\Project\SLC"\controller.ino.bin 0x8000 "C:\Project\SLC"\controller.ino.partitions.bin
Replacing ESP32 fixes the problem. I believe its a reliability issue with ESP32, has anybody faced such reliability issues with ESP32 Wroom?