Baud rate 921600 not working.

[hvishu]

We want to use the maximum baud rate so that flashing can happen quickly in the production line. I see options till 2M, but only able to get it working max baudrate of 460800. Could you tell us if anything need to be done? Also do let me know if you require any further information.

root@vishwanatha-L460:~/esp/rel_v3_0/examples/projects/ecowater# python /home/vishwanatha/esp/rel_v3_0/components/esptool_py/esptool/esptool.py --chip esp32 --port /dev/ttyUSB0 --baud 921600 --before default_reset --after hard_reset write_flash -z --flash_mode dio --flash_freq 40m --flashsize detect 0x8000 build/partitions.bin esptool.py v2.1 Connecting........____....._ Chip is ESP32D0WDQ6 (revision 1) Uploading stub... Running stub... Stub running... Changing baud rate to 921600 Changed. Configuring flash size...

A fatal error occurred: Timed out waiting for packet header root@vishwanatha-L460:~/esp/rel_v3_0/examples/projects/ecowater# python /home/vishwanatha/esp/rel_v3_0/components/esptool_py/esptool/esptool.py --chip esp32 --port /dev/ttyUSB0 --baud 460800 --before default_reset --after hard_reset write_flash -z --flash_mode dio --flash_freq 40m --flash_size detect 0x8000 build/partitions.bin esptool.py v2.1 Connecting........__ Chip is ESP32D0WDQ6 (revision 1) Uploading stub... Running stub... Stub running... Changing baud rate to 460800 Changed. Configuring flash size... Auto-detected Flash size: 4MB Compressed 3072 bytes to 184... Wrote 3072 bytes (184 compressed) at 0x00008000 in 0.0 seconds (effective 3766.4 kbit/s)... Hash of data verified.

Leaving... Hard resetting...

[krzychb]

Hi @hvishu,

If the USB cable is long and / or poor quality, then achievable baudrate is lower than a maximum specified for a given USB-to-serial chip.

[hvishu]

Hi krzychb, I am using FTDI C232HD-DDHSP-0 cable, whose length is about 1.5 m. Also I have used the same cable for transfer data between two pc's at 921600 baud rate and it works well. I feel the cable is good. But if you still insist, do let me know if you want us to try with any particular make and model.

[krzychb]

In my reply I assumed and ordinary USB cable, like for connecting a smart phone to a PC.

Regarding FTDI C232HD-DDHSP-0 cable, basing on specification, it looks like more than well suited to transfer 2Mbaud.

Maybe the issue is with some incompatibility of esptool.py v2.1 with FT232H chip that is used in this specialized cable, Official development boards by Espressif are using one of CP2102, CP2102N or FT2232HL chips and most of testing concerns these particular chips.

I suggest asking a question on esp32.com forum, what experience people have uploading ESP32 with FT232H chip and FTDI C232HD-DDHSP-0 cable in particular.

[projectgus]

Hi @hvishu ,

I think this is probably a signal integrity issue. Looking at the cable you are using, the 1.8M length is on the serial side not the USB side. This is quite a long cable to be sending a ~1MHz 3.3V single-ended signal through.

You may have more success if you can source a serial cable where the majority of the cable length is on the USB side, with short as possible serial leads (USB is a differential protocol with error correction built in, so it's less likely to introduce unrecoverable errors).

You could also take some analog captures of the serial pins with an oscilloscope, this may give you some ideas about the signal quality and what you can do to improve it (ie reduce capacitance, add series resistance, other noise reduction or grounding measures, etc).

Regarding the underlying problem of production time: If you're using Espressif modules (WROVER, WROOM, etc) and have a high enough MOQ then Espressif can supply pre-flashed modules with your firmware already on them for factory use. You can ask Espressif sales department about this. If you're using an external flash chip rather than a module, most flash manufacturers can also provide pre-flashed chips.

I'm going to close this issue because I don't think there is anything we can do from the ESP-IDF side. If you think there's a software bug in esptool then feel free to open an issue on that repo, however I think this is purely down to signal integrity and there isn't much that we can do from the software side.

Angus