Constant reboot and "Could not auto-detect Flash size" when flashing

[smeedy]

Hi all,

I have some 10 identical custom boards made, with one acting somewhat irregular. It keeps rebooting on a

Code: Select all

rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
flash read err, 1000
Falling back to built-in command interpreter.
OK
>ets Jun  8 2016 00:22:57

rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
flash read err, 1000
..

Pulling IO0 low will put it in the waiting for download, but flashing will lead to a

Code: Select all

Flashing binaries to serial port /dev/cu.usbserial-FTXVKLTN (app at offset 0x10000)...
esptool.py v2.0-beta3
Connecting....
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 921600
Changed.
Configuring flash size...
Warning: Could not auto-detect Flash size (FlashID=0xffffff, SizeID=0xff), defaulting to 4MB
Flash params set to 0x0220

A fatal error occurred: Timed out waiting for packet content
make: *** [flash] Error 2

I'm sort of sure I've seen this one working, but I might have give it a push when using a faulty FTDI cable (lot of garbage in between the default boot message) and trying to flash it the first time. Switching cables did work out for all the others, but now I'm stuck on this one.

Should I pull out the hot air and change the chip?

kind regards,
Martijn

[ESP_Angus]

From the symptoms, I'd guess one of these problems (most likely first):

• Cold joint on the SPI flash signal connections (at either the ESP32 or the SPI flash chip)
• Power problems with the SPI flash rail (brownouts or a cold joint somewhere in the power rail or decoupling.)
• Bad SPI flash chip.

Switching cables did work out for all the others, but now I'm stuck on this one.

I'm not sure exactly what you mean, but it makes it sound like something may possibly be borderline in the design. How are the ESP32s powered?

[smeedy]

I had GPIO6 connected to the Din of a neopixel in the design. See a previous post on this on. We did a hardwire patch on the boards using GPIO19 instead and releasing the IO6. All nine are playing nice now and we can indeed light the SK8612. This one has the bootloop.

Boards are powered from a FTDI connector and/or from 5V USB with an LM117MP33. See the details on the attached screenshots. I'm not expecting problems here.

On the part of switching cables.. Indeed a little vague. I suspected a faulty cable, but all cables eventually turned out working fine on all the other PCBs and devboards. So come to think of it, this particular board gave the interference from the start, and trying to flash it probably corrupted the bootloader.

So this looks something on this specimen. So I can start brushing up my basic skills on the ROM console, or I can solder on a new WROOM32 as all the electricals measure out fine.

Thanks for your time,
Martijn