Hi @peer69,
Thought you might appreciate the following additional information and I had some questions on potential causes.
There’s a repository on GitHub that has both a WT32-ETH01 Schematic and datasheet.
Bootstrap Pins
As you know, there are six bootstrapping pins that can affect boot: 0, 2, 4, 5, 12 (MTDI), and 15 (MTDO). Here are some expandable sections, so you can skip stuff you know:
How IOs 0, 2, 4, 5, and 15 (MTDO) affect boot
| IO0 | IO2 | Boot Mode |
|---|---|---|
| 0 | 0 | Download Boot |
| 0 | 1 | Undocumented test modes |
| 1 | 0 | SPI Boot (default) |
| 1 | 1 | SPI Boot |
For undocumented test modes, IO4, IO5 and IO15 (MTDO) select which of the undocumented test mode is entered. See this post. Additional details are not, however, known to me.
When in “Download Boot” mode, the chip will accept either SDIO or UART input for boot. In this situation, the SDIO falling/rising edge configuration is determined from IO15 and IO5:
| IO15 | IO5 | SDIO sample | SDIO output |
|---|---|---|---|
| 0 | 0 | Falling-edge | Falling-edge |
| 0 | 1 | Falling-edge | Rising-edge |
| 1 | 0 | Rising-edge | Falling-edge |
| 1 | 1 | Rising-edge | Rising-edge |
When in “SPI Boot” mode, IO15 (MTDO) instead defines whether U0TXD outputs debug log during boot.
| IO15 | BootRom Debug Log output |
|---|---|
| 0 | Disabled |
| 1 | Enabled |
How IO12 (MTDI) affects boot
IO12 (MTDI) is the most interesting pin for this discussion, as it controls the default voltage of the internal LDO. Importantly, the general ESP32 datasheet has the following note:
For ESP32 chips that contain an embedded flash, users need to note the logic level of MTDI. For example, ESP32-D2WD contains an embedded flash that operates at 1.8 V, therefore, the MTDI should be pulled high.
- IO12 (MTDI) – This defines the voltage of the internal LDO (high = 1.8V, low/default = 3.3V). ESP32-D2WD has internal flash that runs at 1.8V, so MTDI must be pulled high on those boards, for example.
- IO12 is also known as: ADC2_CH5, TOUCH5, RTC_GPIO15, MTDI,
HSPIQ, HS2_DATA2, SD_DATA2, EMAC_TXD3
Original firmware bootstrap pins
| Pin | Value | Notes |
|---|---|---|
| IO12 | 0 | 3.3V flash voltage |
| IO0 | 1 | SPI_BOOT |
| IO2 | 0 | SPI_BOOT |
| IO4 | 0 | not used |
| IO15 | 1 | Debug output enabled |
| IO5 | 1 | not used |
Testable: Is IO12 the culprit?
On WT32-ETH01, the only bootstrap pin of interest is IO12 (MTDI), as it can cause the voltage supplied to the internal flash to be too low if it reads high.
On the WT32-S1, the schematic shows that IO12 is left floating, with a trace bringing the pin to the exposed header, so only the internal pull-down is keeping the signal low. If you have connected IO12 to a peripheral, then perhaps the peripheral is holding the line high and/or there’s too much capacitance to drain quickly enough for boot?
The good news is that the voltage regulator settings that are affected by IO12 can be forced … using efuse settings. After verifying your WT32-ETH01 board’s settings, you could force them via efuse settings. If the problem persists, then it’s not a problem with the bootstrap value of IO12.
Most likely, it’s not the bootstrap pins, but it’s a possibility often overlooked. Instead, as you suggest, perhaps with ethernet attached, there’s just too high a surge of current required.
If true, that would explain why the large capacitor helps, as it would provide a buffer for those surges. But, that leaves me somewhat uncomfortable as the capacitor size is a guess, and there’s no guarantee it’d be enough for edge cases.
Was there ever a true cause discovered?