Any ideas?

Hi, we are manufacturing dozens of ESP32-based devices, and most of them work perfectly. We have a few (e.g. 2% of the production run) which otherwise seem to work fine, as long as the other hardware is related, but the WiFi seems to be dead; the chip WiFi network scan results in 0 networks visible,...

The engine signal is optoisolated in the new revision. Also its conditioning circuitry is moved off to a small PCB, separate from the main PCB which has the ESP.

No worries. Yeah, it does seem far fetched, but weirder things have happened. If power consumption isn't an issue, you could easily lower it. Power consumption isn't an issue, I'll lower it. Okay, that makes sense. To clarify, the second batch of devices never overwrite their bootloader? Or they do...

Hello Sam, sorry for the late reply. I wasn't near a PC the last week. Could it be that 360k isnt aggressive enough of a pull down? Hmm, the datasheet states that pin 12 has an internal pull-down during bootstrapping; so it's two pulldowns in parallel, I think this should be enough, as there is real...

Yes, pin 12 is pulled down with 360k to GND. Nothing else drives this pin (it's just the ESP pin, the 360k, and a MOSFET gate). Basically this pin is always logic 0, the only time it's driven high is during lab testing.

@WiFive, no, I cannot correlate it with any write operations. I don't use the NVS or the filesystem. OTA is used regularly, but the failure is not during the OTA, e.g. to give an example - Device X works happily all April - An OTA update is applied on May 3rd - The device continues to work happily, ...

@WiFive, my programming sequence is that the ESP with the blank flash chip is first powered through the normal power source, likely for more than 5 seconds. Only then I connect the serial harness and run esptool. Also, the devices flashed like this work. They work continuously for months, they devel...

Yeah, I haven't got to the hardware interventions part, because - only this sector shows defective, and I'm reading 1 MB, if it were an electrical issue during reading, I'd expect to affect 100% of the dumps - also (based on experience from other devices), when you overwrite this sector, the weak bi...

Lol, what an interesting development... I got two devices back, both "bricked" in the same way. "62" is encrypted, and shows damage in its first bootloader sector; its entropy is only ~0.62 and the histogram shows high prevalence of bytes towards 0xff. More interestingly, as discussed earlier in the...