Programming the ESP32 on a custom board
Posted: Sat Apr 08, 2017 10:12 pm
I've built a custom board which, among other things, incorporates an ESP32. I've been trying to validate my design, but I've run into stumbling blocks getting it programmed.
The first time I tried to program it (using the esp-idf toolchain), it appeared to go through properly. Subsequent attempts have all failed:
On the debug console, I'm seeing:
with the RTCWDT_RTC_RESET message repeated many times.
Now, based on knowledge of the boot process, this is likely the result of reading a corrupted image from flash -- the first-stage bootloader will pull the boot image from flash and start it executing, but it never disables the watchdog and so the system is reset. I'm at a loss, however, to discover exactly how the flashing process is failing. I've verified the connections to the SPI flash asic we're using, and they seem correct (it's a M25P16-VMC6TG). I've tried all four flash SPI modes in the config, and all exhibit the same behavior, as well as slowing down the flashing frequency to the lowest available (20 MHz).
We've used a 26 MHz crystal, but most reference designs use 40 MHz. I haven't found any PLL settings, so I've been operating under the assumption that the PLL autodetects input frequency. Is this correct?
I've attached a pdf of our schematic -- it's one part of a much larger design, so I've only included the relevant portion.
I'm currently at a loss for further tests to perform, so if anyone more experienced than I has ideas for debugging steps I'd love to hear them. Thanks in advance!
The first time I tried to program it (using the esp-idf toolchain), it appeared to go through properly. Subsequent attempts have all failed:
Code: Select all
Flashing binaries to serial port /dev/ttyUSB0 (app at offset 0x10000)...
esptool.py v2.0-beta2
Connecting.....
Uploading stub...
Running stub...
Stub running...
Attaching SPI flash...
Configuring flash size...
Auto-detected Flash size: 2MB
Flash params set to 0x0212
Wrote 16384 bytes at 0x00001000 in 1.5 seconds (90.3 kbit/s)...
File md5: cda18b3158b3f80b79cea718b938b7bb
Flash md5: be72c9f91de30cda3113e685e98e93d3
MD5 of 0xFF is cc08804af1c2587c06c7f489b6488be1
A fatal error occurred: MD5 of file does not match data in flash!
/home/austin/scratch/esp-idf/components/esptool_py/Makefile.projbuild:52: recipe for target 'flash' failedCode: Select all
rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
ets Jun 8 2016 00:22:57
rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0x00
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0008,len:8
load:0xffffffff,len:-1
ets Jun 8 2016 00:22:57Now, based on knowledge of the boot process, this is likely the result of reading a corrupted image from flash -- the first-stage bootloader will pull the boot image from flash and start it executing, but it never disables the watchdog and so the system is reset. I'm at a loss, however, to discover exactly how the flashing process is failing. I've verified the connections to the SPI flash asic we're using, and they seem correct (it's a M25P16-VMC6TG). I've tried all four flash SPI modes in the config, and all exhibit the same behavior, as well as slowing down the flashing frequency to the lowest available (20 MHz).
We've used a 26 MHz crystal, but most reference designs use 40 MHz. I haven't found any PLL settings, so I've been operating under the assumption that the PLL autodetects input frequency. Is this correct?
I've attached a pdf of our schematic -- it's one part of a much larger design, so I've only included the relevant portion.
I'm currently at a loss for further tests to perform, so if anyone more experienced than I has ideas for debugging steps I'd love to hear them. Thanks in advance!