ESP32 Forum

Hi All,

I inherited an untested target board for a new design that contains an ESP32-U4WDH. It was originally designed with a different ESP32, and not all corrections were made, but I've modified it to comply with the requirements stated on the ESP32 online "Schematic Checklist." I'm using VS Code with ESP-IDF in Windows 11. I started with a simple program derived from a Blink example. It programs an runs successfully on an ESP32 DevKit V1. When I try to upload it to the ESP32-U4WDH on the target board via UART, I get the following output on the terminal:

[Codebox] * Executing task in folder blink: C:\Users\rvice\.espressif\python_env\idf5.1_py3.11_env\Scripts\python.exe C:\Users\rvice\esp\esp-idf\components\esptool_py\esptool\esptool.py -p COM8 -b 115200 --before default_reset --after hard_reset --chip esp32 write_flash --flash_mode dio --flash_freq 40m --flash_size 2MB 0x1000 bootloader/bootloader.bin 0x10000 blink.bin 0x8000 partition_table/partition-table.bin

esptool.py v4.7.dev3
Serial port COM8
Connecting......
Chip is ESP32-U4WDH (revision v3.1)
Features: WiFi, BT, Dual Core, 240MHz, Embedded Flash, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: cc:7b:5c:84:0c:48
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Flash will be erased from 0x00001000 to 0x00007fff...
Flash will be erased from 0x00010000 to 0x0003cfff...
Flash will be erased from 0x00008000 to 0x00008fff...
Compressed 26640 bytes to 16683...
Writing at 0x00007690... (100 %)
A fatal error occurred: Serial data stream stopped: Possible serial noise or corruption.[/Codebox]

I've scoured the web and tried a lot of different things to resolve the issue, but nothing has helped.
Here are a few things I've tried:
1. Reduce BAUD rate.
2. Different USB cable and bridge.
3. Used Arduino IDE in addition to VS Code.

I know the power supply is clean. I've put a scope and logic anaylzer on TXD and RXD and see that the signals are pretty clean. The ESP32-U4WDH sends the appropriate output stream over TXD at power up.

Here's what the TXD output stream looks like at powerup and just after taking IO0 low:
Where can I find the script that is running the pgm tool? I'd like to see exactly what's happening after programming that first section of memory that shows 100%. Normally I would see how many bytes were written and that the Hash has been verified. Where is the script that streams that info?

Can anyone point me in a direction on this?

Thanks,
robin

Is your MTDI pin connected to anything? If it's high on bootup, the flash will only get 1.8V and generally it won't like that in this configuration.

Hi ESP_Sprite,

Thanks for your feedback.

MTDI is floating. In the original design (and on my target board) they had a pullup resistor, that was causing VDD_SDIO to run at 1.8V. However, I've removed that resistor and now the MTDI pin is floating. Now I measure 3.3V at pin 26 VDD_SDIO. I put a 1uF ceramic cap on it.

GPIO0 is floating, and I manually, momentarily take it low during power-up to get the ESP32 in programming mode. I can see that's happening by monitoring the RXD pin. Then, when I upload the binary files, I see a bunch of data uploading until the VS Code terminal indicates 100%, and that's when the error pops up.

GPIO2 stays low throughout the whole process.

CHIP_PU stays high throughout the whole process.

More thoughts?

Thanks,
robin

Can you read the status register of the flash chip? You can do that using `esptool.py read_flash_status`.

I'm not sure why my last post didn't appear on the forum, but I'll try again.

I'm not able to run the esptool.py commands on my Windows 11 PC. I don't know why. I've researched online, and I think it should be working, but it isn't. Python and esptools are loaded on the machine and are working when invoked from VS Code, but I can't seem to get the tools to work in a command or powershell window. It's not a path issue.

In the absence of having the flash status register info, I'll provide an update on what I've found:
1. With a logic analyzer, I've captured UART activity during the program upload process. The ESP32 DevKitM-1, which programs properly, shows CHIP_PU transitions low, then high, then the ESP32 transmits some information starting with "ets Jul 29 2019..." This message concludes with "room 4 0x0d 0x0a load:0x400804,le0xff"
2. The Target board starts out the same, but stops in the middle of the ESP32 message. CHIP_PU goes low, then high, then the ESP32 transmits some information starting with "ets Jul 29 2019...", same as above. However, here's where it's different, the message is much shorter and concludes with "FAST_FLASH_BOOT)0x0D 0x0A". This is consistent, happens every time, regardless of BAUD rate.

I don't see any changes in the CHIP_PU or GPIO0 pins when the message halts. I have noticed glitches in the CHIP_PU line on the logic analyzer, but am unable to confirm them with a scope. The glitches are either in the lines feeding signal to the analyzer, or in the analyzer software, but don't appear to be real.

I've confirmed that the DTR and RTS signals are the same on both the good and bad units. Also, GPIO0 and CHIP_PU are the same on both units up until the ESP transmit message mentioned above.

I could really use some help on this. It isn't going away. I have a CM with all parts ready to manufacture the first lot of hardware, but I won't let them proceed until this issue is solved.

Any and all help is greatly appreciated.

Thanks,
robin

Here's another update: I've captured the entire load sequence in a Docklight log for each of the two test units (ESP32 DevKitM-1 and my Target board).

They are very similar in the beginning, but the log for the Target board shows where it stops long before the upload is complete.

Again, thanks,
robin

One critical problem in your board is U4WDH has differen flash assignments wrt ESP32-D0WD-V3. In U4WDH, GPIO16 and GPIO17 are used by flash, you could check this in ESP32 datasheet. Have a try to fix this point and see if you could download firmware.

Thanks ESP_LJH, that was the problem.

I saw that early on, and discounted it as the reason for blocking programming, because IO16-17 were connected only to high impedance FET gates. I still don't quite know why having them connected to FET gates would prevent programming. Maybe gate capacitance was enough to throw off timing or levels? If that were the case, I would have expected to see some differences in various BAUD rates. The failures were identical every time, regardless of BAUD rate.

Anyway, removing the FETs was in my notes from when I first got the design. It was my plan to pull them off the board as a last ditch effort even before I got your message.

Either way, I wish I had tried this right away. It would have saved a lot of troubleshooting time and effort.

Thanks again!
robin