ESP32 Forum

I've got a system with a SAMD51 microcontroller connected to an ESP32 WROOM32 module. I'm uning the Arduino IDE and I'm trying to use the SAMD51 as a USB to Serial converter in order to flash new code onto the ESP32.

The SAMD51 (An Adafruit Metro M4) sets the appropriate pins on the ESP32 on startup to set it into bootloader mode and I get this message on a serial monitor when it starts up:

ets Jun 8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x3 (DOWNLOAD_BOOT(UART0/UART1/SDIO_REI_REO_V2))
waiting for download

This data comes from the ESP32, into the D51 via a UART and then to the USB Serial port so I know that the ESP32 is booting up correctly into bootloader mode. I have also done loopback tests to ensure that the serial connection between the two is working both ways and is not producing errors (at 115200 baud).

When I pick the ESP32 Dev Module in the Arduino IDE, select the serial port and attempt to compile and uploade test code to the ESP32 it gets stuck trying to communicate and I get a timeout error:

esptool.py v2.3.1
Connecting........_____....._____....._____....._____....._____.....

Nothing I have done so far has fixed this and I don't understand why - Is it to do with the USB device being identified as an Adafruit Metro M4 or is it something else?

Hi SamD,

If you can run esptool.py from the command line with the --trace option (ie "esptool.py --trace -p PORT flash_id") then you may get some clues (ie is any data getting read back from the ESP32 at all?)

Historically, there have been a few issues with unusual timing of data sent/received when microcontroller USB-CDC implementations are being used to talk to ESP32. If the micro is buffering data in a way which causes long pauses between parts of the serial message, it can cause some problems.

Also at least for Arduino USB-CDC there have been some issues where the USB-CDC firmware stops sending serial data entirely while the RTS control line is disabled. Probably worth checking for this as well.

As well as the --trace option, if you have a logic analyzer try connecting it to ESP32 TX/RX. Compare what you see there with the --trace output, and maybe also compare timing with the serial comms to a working ESP32 dev board
.

Thanks for the reply. I will try using the trace option as you suggested.

I've hooked up an FTDU USB serial converter to one of the other serial ports on the SAMD51 and created a software bridge between that port and the one connected to the ESP32. I ran the same test, starting the ESP32 in bootloader mode and using the USB serial port bridge to attempt an upload using the Arduino IDE.

It almost works - I get the message below in the arduino IDE.

So it does look like the USB CDC is the main problem, but the upload is still failing half way through.

At the moment I am using the Arduino Serial.read() and Serial.write() functions to bridge the two ports and there may still be some delays there due to the way it buffers data.

Because this is a bespoke product for a client I need to find a workaround for this problem - I can supply them with a dongle that will attach to the spare SAMD51 serial port so if I can get the upload to complete without errors then its fine - the problem is solved for me.

Is this likely to still be a timing issue and if so is it fixable if I work directly with the SAMD51 SERCOM interrupts and registers to bypass any buffering the Arduino Serial lib might be doing?

esptool.py v2.3.1
Connecting......
Chip is ESP32D0WDQ6 (revision (unknown 0xa))
Features: WiFi, BT, Dual Core, VRef calibration in efuse
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Auto-detected Flash size: 4MB
Compressed 8192 bytes to 47...

Writing at 0x0000e000... (100 %)
Wrote 8192 bytes (47 compressed) at 0x0000e000 in 0.0 seconds (effective 4096.0 kbit/s)...
Hash of data verified.
Compressed 12480 bytes to 8255...

Writing at 0x00001000... (100 %)
Wrote 12480 bytes (8255 compressed) at 0x00001000 in 0.8 seconds (effective 132.6 kbit/s)...
Hash of data verified.
Compressed 555184 bytes to 340404...

Writing at 0x00010000... (4 %)
A fatal error occurred: Failed to write compressed data to flash after seq 0 (result was C100)
A fatal error occurred: Failed to write compressed data to flash after seq 0 (result was C100)

Error code C1 is ESP_BAD_DATA_CHECKSUM.

I don't really understand the description of the test. Is the configuration with the FTDI cable sending the upload through the FTDI cable, or are you watching the upload from the CDC via the FTDI rather than via a logic analyzer?

If the former, is it possible the Atmel chip and the FTDI chip TX are both trying to drive the serial line at the same time?

Does the failed-part-way upload fail in the exact same place each time? It's possible there is some secondary electrical issue like noise or power supply problems with the ESP32...

The route from my computer to the ESP32 and back is as follows:
USB -> FTDI Adapter -> SAMD51 SERCOMx -> SAMD51 SERCOMy -> ESP32 Serial

I'm watching the Arduino IDE messages it produces during the upload.

The data passes through the SAMD51 with a short sketch that copies any data between the two instances of the Serial ports (for each SERCOM) using the Arduino Serial functions. Both sercoms are set to 115200 baud: Using this setup produces the error part way through the upload. The error happens the same way each time.

I have a header on my PCB that lets me plug the FTDI adapter straight into the Tx and Rx pins for the ESP32. If I upload a sketch to the SAMD51 that disables the SERCOM pins connected to the ESP32 (Setting them to inputs) I can upload code to the ESP32 without a problem. It only stalls when I use the SAMD51 as a bridge between the FTDI and the ESP32.

I suppose its possible it could be electrical, but unless the FTDI drives the pins differently than the SERCOM I would expect to still see problems when I bypass the SAMD51.

Like many people, I often get the dreaded "Failed to write compressed data to flash" when using esptool. In my case it is running on a Windows PC, talking to a Teensy 3.5 which is relaying the serial data to and from the ESP32.

It seems like a timing problem, because if I turn on the trace mode of the python program (using --trace on the command line), the odds of getting all the way through flashing the memory goes up from about 5% to about 50%. Still annoying, but at least it works if I try enough times.

I've seen complaints about this dating back years. Doesn't anyone have the correct solution to the problem?

Summary

What worked for me after several days of anguish was switching USB to RS323 interfaces
- from FTDI232 (FT232RL), assumed legitimate
- to AiThinker (CH340G)

My symptoms using FTDI: flashing with esptool failed early with some variation of the following
Writing at 0x00009
A fatal error occurred: Failed to write compressed data to flash after seq 2 (result was C100)

I compared what was written before the fail to my "bare" ESP32 and it "matched" the flashing of my ESP32 DevKit module. So some data was getting written.

---
Setup

I had no problems with the Dev.Kit.V1 (has it own onboard interface, Silocon Labs CP210x)

Problems started with 2 "bare" ESP WROOM 32 modules. Just for debug, I mounted the first on an 8 pin header plugged into a breadboard. Connections were made with very short lengths of wirewrap from module to header. ESP suspended in "space" via the 8 wires to the header. Too sloppy to work? Pins brought out: GND, GPIO15, GPIO2, GPIO0, Rx, Tx, Vcc, EN. A difficult solder job, especially ground pin -- I only used 1 of the 3 available.

gnd from RS232 to breadboard
GPIO15 pulled up
GPIO2 pulled down
GPIO0 pulled up, also connected to push button to gnd
Rx to Tx of RS232 to USB to Windows 7 computer
Tx to Rx of RS232
5v from RS232 (straight through from computer) to LDO regulator on breadboard (3.3v). I felt interface did not have sufficient power to drive 3.3v by itself. I did not try.
EN pulled up, also connected to push button to gnd
all pullups/pulldowns in the range of 10-20k, whatever came out of the bin
additionally, breadboard contained some decoupling caps

---
Burn process

power ESP by connecting usb to computer
press and hold boot (flash) button (to bring from high to low)
press and release EN to reset ESP (high, low, high)
start esptool
after flashing % starts, release boot button (to bring high)

for me, the call to python looked like this
..\python c:\esptool\esptool.py -b 115200 --port COM5 write_flash --flash_freq 80m 0x1000 esp32-idf4-20200110-v1.12-45-gbfbd94401.bin

failure with FTDI looked like this

esptool.py v2.8
Serial port COM6
Connecting........__
Detecting chip type... ESP32
Chip is ESP32D0WDQ6 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: 4c:11:ae:cc:10:58
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Auto-detected Flash size: 4MB
Flash params set to 0x022f
Compressed 1408336 bytes to 894584...
Writing at 0x00009000... (5 %)
A fatal error occurred: Failed to write compressed data to flash after seq 2 (result was C100)

Success with AiThinker looked like this

esptool.py v2.8
Serial port COM6
Connecting........__
Detecting chip type... ESP32
Chip is ESP32D0WDQ6 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: 4c:11:ae:cc:10:58
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Auto-detected Flash size: 4MB
Flash params set to 0x022f
Compressed 1408336 bytes to 894584...
Writing at 0x00009000... (5 %)
A fatal error occurred: Failed to write compressed data to flash after seq 2 (result was C100)

No other changes were made between AiThinker and FTDI, just swapping out the 4 lines from the USB to RS232 header.

---
I repeated this process on a second "bare" ESP32 mounted on an old wirewrap board with wirewrap to connect to the board pins. All 3 gnd pins tied to the ground plane. 3.3v connected to the power plane. Significant decoupling between gnd and 3.3v very close to the ESP. 0.1 uF from EN to ground. EN and GPIO0 10k chip resistor pullups to Vcc. Relatively "short" Tx and Rx lines. None of this helped with the FTDI.

I tried the RTS and DTR connections to EN and GPIO0, resp. This did not work at all with esptool.

I did not try the 2x transistor and 2x resistor network for EN and GPIO0 timing. I doubt it would have helped since flashing started fine.

I tried -- trace in esptool which had been reported as helping a little bit. This did not help.

I tried changing the priority of esptool in process explorer to "near real time". This did not help.

I have another FTDI and another AI Thinker USB to RS232. I did not try either of those. They are the same vintage as the two I tried.

FYI: Flashing ESP8266s has not been a problem using the FTDI interface.

Hope this helps.







-

Here is an update to my Jan 12 post.

All my "FTDI232" adapters are FAKES, as they have the same serial number. Apologies to the OEM.

I have also acquired at CP2102 based adapter, and it seems fine. Downloading can be performed at very high rates. The following were fine
python c:\esptool\esptool.py -b 115200 --port COM10 read_flash 0x00000 0x400000 esp8266_10_CP2102_1_4M.bin
python c:\esptool\esptool.py -b 921600 --port COM10 read_flash 0x00000 0x400000 esp8266_10_CP2102_1_8x_4M.bin
python c:\esptool\esptool.py -b 460800 --port COM10 read_flash 0x00000 0x400000 esp8266_10_CP2102_1_4x_4M.bin
python c:\esptool\esptool.py -b 230400 --port COM10 read_flash 0x00000 0x400000 esp8266_10_CP2102_1_2x_4M.bin

flashing was fine
python c:\esptool\esptool.py -b 115200 --port COM10 write_flash --flash_freq 80m 0x000000 E:\IoT\ESP8266\NodeMCU\Firmware\custom\nodemcu-master-19-modules-2020-02-20-03-19-52-float.bin