TLDR: It was likely a layout issue on my board.
I've seen the issue twice now:
Before it happens, I'm able to use the USB-CDC bootloader to flash and run firmware. However, sometimes after leaving a firmware running for some time (2-8 hours), it crashes, and doesn't start again after cycling power. Normally my computer will then not be able to enumerate the USB device, however if I get lucky with the timing then I can connect to it with idf.py monitor, and I see this message in the log (repeated in a loop):
Code: Select all
I (34) boot: ESP-IDF v4.3-1-g1d4dc79ae 2nd stage bootloader
I (35) boot: compile time 15:13:57
I (35) boot: chip revision: 0
I (35) qio_mode: Enabling default flash chip QIO
I (35) boot.esp32s2: SPI Speed : 80MHz
I (36) boot.esp32s2: SPI Mode : QIO
I (36) boot.esp32s2: SPI Flash Size : 4MB
I (36) boot: Enabling RNG early entropy source...
E (36) flash_parts: partition 3 invalid magic number 0xefef
E (37) boot: Failed to verify partition table
E (37) boot: load partition table error!
Re-programming the device using the hardware bootloader in DFU mode always works:
Code: Select all
Executing action: dfu-flash
Running make in directory /home/matt/Blinkinlabs-Repos/iced_espresso/examples/CM-2/build
Executing "make -j 6 dfu-flash"...
Command list: dfu-util;-d;303a:2;-D;/home/matt/Blinkinlabs-Repos/iced_espresso/examples/CM-2/build/dfu.bin
dfu-util 0.9
Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/
Opening DFU capable USB device...
ID 303a:0002
Run-time device DFU version 0110
Claiming USB DFU Runtime Interface...
Determining device status: state = appIDLE, status = 0
Device really in Runtime Mode, send DFU detach request...
Device will detach and reattach...
dfu-util: error detaching
Opening DFU USB Device...
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 0110
Device returned transfer size 64
Copying data from PC to DFU device
Download [=========================] 100% 317440 bytes
Download done.
state(2) = dfuIDLE, status(0) = No error condition is present
Done!
Built target dfu-flash
Done
Unfortunately, after a successful flash, the part still didn't boot.
Today I was able to make the issue repeatable. At 80 MHz, setting either of the quad modes (QIO or QOUT) prevented the firmware from booting, but the dual modes (DIO and DOUT) both work. At 20MHz, all options appeared to work.
The issue seems to be with my board design, I had those signals routed over a short distance to an FPGA (as part of an experiment to make a memory-mapped peripheral). The tracks must have been just the right size to make the internal flash communications marginal, and cutting the traces near the ESP pads seems to resolve the issue.
If you run across specs for the internal memories, it would still be good to know
