Can't program the ESP32 with VSCode

[Palonso]

Hi,

I'm using VSCode to compile and program a custom ESP32 device and I'm not able to program it.
Here is the thing, using VSCode on my Linux Desktop PC I can program, monitor and debug the device with no problem at all BUT when I tried compiling and programming with my Windows Laptop (also using VSCode) I get the next message:

Code: Select all

> Executing task: C:\Users\Asus\.espressif\python_env\idf4.3_py3.8_env\Scripts\python.exe C:\Users\Asus\esp\esp-idf\tools\idf_size.py c:\Users\Asus\Documentos\GitHub\Firmware\build\firmware.map <

Total sizes:
Used static DRAM:   32492 bytes (  92088 remain, 26.1% used)
      .data size:   21596 bytes
      .bss  size:   10896 bytes
Used static IRAM:  120939 bytes (  10133 remain, 92.3% used)
      .text size:  119912 bytes
   .vectors size:    1027 bytes
Used stat D/IRAM:  153431 bytes ( 102221 remain, 60.0% used)
      .data size:   21596 bytes
      .bss  size:   10896 bytes
      .text size:  119912 bytes
   .vectors size:    1027 bytes
Used Flash size : 1490543 bytes
      .text     : 1101443 bytes
      .rodata   :  388844 bytes
Total image size: 1775613 bytes (.bin may be padded larger)

> Executing task: C:\Users\Asus\.espressif\python_env\idf4.3_py3.8_env\Scripts\python.exe C:\Users\Asus\esp\esp-idf\components\esptool_py\esptool\esptool.py -p COM3 -b 460800 --before default_reset --after hard_reset --chip esp32 write_flash --flash_mode dio --flash_freq 40m --flash_size detect 0x690000 firmware.bin 0x1000 bootloader/bootloader.bin 0x8000 partition_table/partition-table.bin 0x689000 ota_data_initial.bin <

esptool.py v3.2-dev
Serial port COM3
Connecting......................................

A fatal error occurred: Failed to connect to ESP32: Timed out waiting for packet header
The terminal process "C:\Users\Asus\.espressif\python_env\idf4.3_py3.8_env\Scripts\python.exe 'C:\Users\Asus\esp\esp-idf\components\esptool_py\esptool\esptool.py', '-p', 'COM3', '-b', '460800', '--before', 'default_reset', '--after', 'hard_reset', '--chip', 'esp32', 'write_flash', '--flash_mode', 'dio', '--flash_freq', '40m', '--flash_size', 'detect', '0x690000', 'firmware.bin', '0x1000', 'bootloader/bootloader.bin', '0x8000', 'partition_table/partition-table.bin', '0x689000', 'ota_data_initial.bin'" terminated with exit code: 2.

Any idea of what could be happening?

It used to work but suddenly it stopped working.

Regards,
P

[a2800276]

Can you run monitor on Windows? Are you sure COM3 is the correct port? Are you sure nothing else (`idf.py monitor`?) is running and blocking your connection?

[Palonso]

Yes I can, here is a picture of it running:

Screenshot 2022-05-26 120644.png (49.11 KiB) Viewed 6403 times

I'm also sure COM3 is the correct port since is the only port installed/detected:

Screenshot 2022-05-26 120855.png (19.88 KiB) Viewed 6403 times

And nothing else is running 'idf.py monitor' therefore blocking the programming process, any idea what is happenning?

Regards,
P

[ESP_Sprite]

Could be a timing issue. Can you connect an 10uF capacitor between the EN line of the ESP32 and ground? Alternatively, you can also check if programming while holding the IO0 button (if your board has it) or grounding GPIO0 works.

[Palonso]

Hi ESP_Sprite,

The 10uF capacitor seems to work, my question is why does this happen?
When I use the desktop computer the device is programmed without problem, but when using the laptop a 10uF capacitor is needed?

Should I always use this 10uF cap? for example in a custom design, I already use a 0.1uF capacitor as recommended in hardware design guide but now it seems it depends on the PC I want to use to program it.

Is there any way to avoid this capacitor?

Regards,
P

[ESP_Sprite]

It's because the programming process depends on certain timing characteristics when setting DTR and DSR on the USB-serial converter: if the delay between changes to those is too low, the ESP32 can come out of reset before IO0 is low and programming will fail. The 10U capacitor is a 'brute-force' way to keep the ESP32 in reset longer. (Note that I think the datasheet advises an 10K/1u RC network, if you used an 0.1u there, upgrading it to what the datasheet advises may already be enough.)

In general: You can generally use any cap you want in that reset circuit, but using a larger cap has the trade-off that the ESP32 will start working later after the device powers up. This can be an issue for e.g. a WiFi lightbulb, but if it doesn't affect you, feel free to whack an 10uF there in production.