Welcome to this troubleshooting video for
ESP32 code uploads! If you've encountered issues with code uploads
to LOLIN D32 and D32 PRO boards, you're not alone. In this video, we'll delve into a frequent
issue with ESP32 code uploads - an incorrect upload sequence that can impede the board
from transitioning to the appropriate bootloader mode. We'll discuss troubleshooting steps and solutions
to overcome this challenge. In this video, we'll start by examining the
symptoms of the issue, using the Lolin D32 Pro board with the original ESP32 chip. Although the board was working fine before,
I haven't used it for a long time. Let's take a closer look at the symptoms of
the problem. When attempting to upload code to an ESP32,
you may encounter timeout errors or receive a specific error message, such as: Failed
to connect to ESP32-Wrong boot mode detected (0x37)! This error indicates that the board was not
switched to the correct mode during the upload process. But what exactly does the "0x37" code mean? Let's delve into this mystery and uncover
the root cause of the issue. During our investigation, we discovered that
when we restart the board with the Serial Monitor Tool open, we can clearly see that
the board is still in the standard boot mode from the flash memory, with a boot code of
"0x37" (SPI_FAST_FLASH_BOOT). This indicates that the upload procedure did
not correctly switch the board to the appropriate mode as expected. This finding sheds further light on the root
cause of the issue and emphasizes the need to address the incorrect mode switching during
code uploads to the ESP32. After researching various discussions and
forums regarding the ESP32 code upload issue, I came across a detailed explanation by Mike
Teachman that specifically addresses the problem with Lolin D32 boards. According to his analysis, the root cause
of the problem is an undersized Reset capacitor. The schematic for Lolin D32 boards shows a
100 Nanofarads capacitor to ground and a 10 kilo resistor to 3.3 volts, but this results
in the Reset signal rising too quickly, causing the ESP32 to detect IO0 in the HIGH state. As a result, the ESP32 boots from SPI flash
instead of entering the bootloader, leading to the code upload failure. However, Mike Teachman suggests that by increasing
the capacitance to 1 microfarad, the Reset rise time increases to about 30 ms, as highlighted
in blue in the AFTER scope capture. This longer rise time ensures that IO0 is
sampled as Low, triggering the ESP32 to enter the bootloader correctly. When troubleshooting the code upload issue,
there are several steps that can be taken. First, it's recommended to test the upload
on different PCs with various cables to rule out any potential issues with hardware. Additionally, lowering the Upload Speed can
be tried to see if it resolves the problem. As for solutions, one option is to manually
switch the board to bootloader mode by shorting IO0 with GND. This prepares the board for code upload, but
it's important to manually disconnect it and reset it to boot from flash after the upload
is complete. Another solution, as suggested by Mike Teachman,
is to add an additional capacitor (1uF) between Reset (labeled RS or RST on the boards) to
restore the automatic mode switch initiated by CH340. This ensures that the board is restarted in
the correct mode after the code upload, eliminating the need for manual intervention. By trying these troubleshooting steps and
implementing the suggested solutions, you can effectively address the code upload issue
and ensure a smooth and successful upload process for your ESP32 board. We hope this video proves helpful in resolving
the issue. If you have encountered this problem or have
any feedback, please share in the comments section. Let us know which type of board you are using. Thank you!
