Programming the ESP32 on a custom board

[austinglaser]

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:

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' failed

On the debug console, I'm seeing:

Code: 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:57

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!

[ESP_Angus]

Hi Austin,

The only thing I can think of is that that particular flash chip model has something unusual in its command set or status register layout that is causing it to lock itself against further writes.

If you run "esptool.py --port PORT read_flash_status" (you can find esptool.py under components/esptool-py/esptool) then what is the output?

If the flash is in a standard SOIC package then you could also try using a programming clip and a flash programmer to communicate with it directly - check the current contents, protection status, and see if flashing it this way makes any difference.

[onehorse]

Had a similar problem:

https://github.com/espressif/arduino-esp32/issues/58

I used this custom bootloader and got my board to work:

https://github.com/kriswiner/ESP32