Damaged or resetable??? ESP32 WROOM Module

[FluxGS]

Thank you for looking! I have an application using the ESP32 WROOM module.
3000 are in operation with code that uses the wifi to conduct a fetch and post to a server.
All the code works well; however with my newest deployment of devices, I am getting units which failed mid operation (such as during a wifi fetch to server).

In diagnostics for a failing unit, when I connect using the IDE programming interface along with "make monitor" and apply power; gibberish comes streaming out rather than the typical boot startup content.

I can place the units into flash mode with IO0 and ENA.

I am unable to erase the flash or to reprogram the flash using "make flash monitor".

Is there some hard reset that can be done, or are the modules damaged?

Note; this application uses 3.6V battery. Understanding that the ESP32 has a Vmax of 3.6v +0.3v, I removed the Voltage regulator from the design to get more current availability during Wifi..

See below, note that all of these devices originally behaved and programmed as expected.


MONITOR
--- idf_monitor on C:/msys32/COM3 115200 ---
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
<Power Up>
f═f═f═f═f═f═f═f═f═f═f═f═f═f═f═f═f═f═f═f═f═f═f═f═f═f═f═f═f═f═f═f═f═f═f═f═f═f═f═f═
f═f═f═f═f═f═f═f═f═f═f═f═f═f═f═f═f═f═f═f═f═f═f═f═f═f═f═f═f═f═f═f═f═f═f═f═f═f═f═f═
f═f═f═f═f═f═f═f═f═f═f═f═f═f═f═f═f═f═f═f═f═f═f═f═f═f═f═f═f═f═f═f═f═f═f═f═f═f═f═f═
f═f═f═f═f═f═f═f═~═fx ~x怘怘═~ffff`═ff═fff`f══f`~ x `
~f══`f`fff ═f ff ═f═f`ff`ff`ff~ff~x x═x~══xf═~═fx ~x~══~f
f~f═ff`f══f`~ x `f═ ═`fff═ff ffff═`ffffffff~ff~x x═x~══xf═~═fx
~x~══~ff~f═ff`f══f`~ x `~f══`f`fff ═f ff ═f═f`ff`ff`ff═~ff~x x
═x~══xf═~═ff═~═f═~═fx ~x怘怘═~ff~f═ff`f══f`~ x `~f═
═`f`fff ═f ff ═f═f`ff`ff`ff~ff~x x═x~══x

<place in down load mode with IOO / ENA sequence, gibberish stops>

<attempt to flash>
$ make flash monitor
Toolchain path: /opt/xtensa-esp32-elf/bin/xtensa-esp32-elf-gcc
Toolchain version: crosstool-ng-1.22.0-80-g6c4433a5
Compiler version: 5.2.0
Python requirements from C:/msys32/home/RogueOne/esp/esp-idf/requirements.txt are satisfied.
Flashing binaries to serial port /COM3 (app at offset 0x10000)...
esptool.py v2.6
Serial port C:/msys32/COM3
Robert-Connecting.......
Chip is ESP32D0WDQ5 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, BLK3 partially reserved, Coding Scheme None
MAC: e8:e8:e7:d2:e5:ec
Uploading stub...
Running stub...

A fatal error occurred: Invalid head of packet (0x66)
make: *** [/home/RogueOne/esp/esp-idf/components/esptool_py/Makefile.projbuild:63: flash] Error 2

[MicroController]

the ESP32 has a Vmax of 3.6v +0.3v

VDD33 = 3.6V:

stress ratings only and functional operation of the device at these or any other conditions beyond those indicated under Recommended Operating Conditions is not implied. Exposure to absolute-maximum-rated conditions for extended periods may affect device reliability.

What's the actual maximum battery voltage/type of battery you have?

How are the modules powered when you try to monitor/flash?

[FluxGS]

The batteries are Saft 3.6v which when brand new, float at about 3.68V.

During Sleep, the batteries would hit this float peak voltage. During a wifi operation, they run about 3.55v.

In my test station, I use a variable dc power supply and see the gibberish behavior described at 3.3V applied.

It sounds like you are suggesting the units are damaged, rather than resetable.

[MicroController]

It sounds like you are suggesting the units are damaged, rather than resetable.

I might be
Was still thinking along the lines of potential voltage mismatch (low battery) between the modules and the USB-UART corrupting data received by the PC or something.

If we can rule out all issues with the monitoring/flashing setup I guess the modules are gone.

[FluxGS]

Thank you and bummer news!

The programming and diagnostic center is sound. I am not a first time hobbyist. I have thousands of modules deployed, which we service and support daily.

This is a new phenomenon and exclusive to our new deployment with the regulator removed and direct power from 3.6v battery.
Regulators were removed because they historically have given us too many brown out resets during operation; while direct battery power has never had a brown out reset during WiFi activity.

This is now a cautionary tale to all the developers who are looking to power the esp32 directly from battery. DONT!

From 1000 units of this new design, we have lost 35, within days of deployment. 3.5% fallout. Hopefully, if they survive this initial phase, they will last.