Carte ESP32 connectée, le port com USB-SERIAL CH340K (COMXX) apparait bien dans le gestionnaire de périphériques Win10 mais n'est pas reconnu en tant que tel dans IDE 1.8.19 ou 2.3.10. IDE affiche simplement COMXX dans la liste des ports disponibles. (quelque soit le port utilisé)
Je pense que si le pilote n'était pas installé, le port ne figurerait pas dans la liste des périphériques W10 tel qu'il se présente actuellement (USB-SERIAL CH340K) . Les propriétés du port affichent bien wch.cn 11/02/2026 4.0 20262
esptool v5.3.1
Serial port COM20:
Connecting.....................................
A fatal error occurred: Failed to connect to ESP32: Wrong boot mode detected (0x13)! The chip needs to be in download mode.
For troubleshooting steps visit: Troubleshooting - ESP32 - — esptool latest documentation
.
le port série sélectionné .
n'existe pas ou votre Arduino n'est pas connectée
Je pense que c'est la cause...
"Wrong boot mode detected (0x13)! The chip needs to be in download mode."
C'est de ma faute... je pense.
Comme pour d'autres types d'ESP32 (comme pour ESP32-CAM que j'utilise depuis longtemps), il est nécessaire de mettre en place une connexion temporaire pour effectuer le téléchargement.
A plus tard pour la suite
En effet, c'est l'une des procédures pour positionner en mode téléchargement des modules utilisant l'ESP32. Curieusement, elle ne semble pas s'appliquer au module FIRE BEETLE de DFROBOT muni de l'ESP32-E
Si c'est le cas qu'est-il préconisé pour cette carte par DF Robot ?
Des élements sonr ils raccordés a des GPIO de la carte lors des tentatives de téleversement ? (certains GPIO peuvent contrarier le flashage par UART + CH340)
Plusieurs solutions existent imposant de la connectique ou l'ajout d'un condensateur...
Et la dernière... appuyer sur RST au moment de la tentative de connexion pour le téléchargement... la suite de petites étoiles...
Et bien, pour ce module, ESP32-E FIREBEETLE V1.0, ça marche ! (test LED tricolore)
Certes, ça oblige à rester attendre que l'opération de téléversement s'initie... et ça prend "un certain temps" pour y arriver...
esptool v5.3.1
Serial port COM19:
Connecting.............................
Connected to ESP32 on COM19:
Chip type: ESP32-D0WD-V3 (revision v3.1)
Features: Wi-Fi, BT, Dual Core + LP Core, 240MHz, Vref calibration in eFuse, Coding Scheme None
Crystal frequency: 40MHz
MAC: 5c:01:3b:3b:24:c8
Writing 'C:\Users\hp\AppData\Local\Temp\arduino_build_740819/RSP32-E_VROOM.ino.bootloader.bin' at 0x00001000...
Flash will be erased from 0x00001000 to 0x00007fff...
Compressed 24992 bytes to 16001...
Writing at 0x00001000 [ ] 0.0% 0/16001 bytes...
Writing at 0x000071a0 [==============================] 100.0% 16001/16001 bytes...
Wrote 24992 bytes (16001 compressed) at 0x00001000 in 0.6 seconds (310.5 kbit/s).
Verifying written data...
Hash of data verified.
Writing 'C:\Users\hp\AppData\Local\Temp\arduino_build_740819/RSP32-E_VROOM.ino.partitions.bin' at 0x00008000...
Flash will be erased from 0x00008000 to 0x00008fff...
Compressed 3072 bytes to 146...
Writing at 0x00008000 [ ] 0.0% 0/146 bytes...
Writing at 0x00008c00 [==============================] 100.0% 146/146 bytes...
Wrote 3072 bytes (146 compressed) at 0x00008000 in 0.1 seconds (472.4 kbit/s).
Verifying written data...
Hash of data verified.
Writing 'C:\Users\hp\AppData\Local\Arduino15\packages\esp32\hardware\esp32\3.3.11/tools/partitions/boot_app0.bin' at 0x0000e000...
Flash will be erased from 0x0000e000 to 0x0000ffff...
Compressed 8192 bytes to 47...
Writing at 0x0000e000 [ ] 0.0% 0/47 bytes...
Writing at 0x00010000 [==============================] 100.0% 47/47 bytes...
Wrote 8192 bytes (47 compressed) at 0x0000e000 in 0.1 seconds (849.9 kbit/s).
Verifying written data...
Hash of data verified.
Writing 'C:\Users\hp\AppData\Local\Temp\arduino_build_740819/RSP32-E_VROOM.ino.bin' at 0x00010000...
Flash will be erased from 0x00010000 to 0x00071fff...
Compressed 399280 bytes to 217841...
Writing at 0x00010000 [ ] 0.0% 0/217841 bytes...
Writing at 0x0001cd59 [=> ] 7.5% 16384/217841 bytes...
Writing at 0x00026e61 [===> ] 15.0% 32768/217841 bytes...
Writing at 0x000301fc [=====> ] 22.6% 49152/217841 bytes...
Writing at 0x0003771b [========> ] 30.1% 65536/217841 bytes...
Writing at 0x0003ea61 [==========> ] 37.6% 81920/217841 bytes...
Writing at 0x000451ac [============> ] 45.1% 98304/217841 bytes...
Writing at 0x0004a8e0 [==============> ] 52.6% 114688/217841 bytes...
Writing at 0x0004fbb2 [=================> ] 60.2% 131072/217841 bytes...
Writing at 0x00055255 [===================> ] 67.7% 147456/217841 bytes...
Writing at 0x0005b00c [=====================> ] 75.2% 163840/217841 bytes...
Writing at 0x000644fb [=======================> ] 82.7% 180224/217841 bytes...
Writing at 0x00069cdd [==========================> ] 90.3% 196608/217841 bytes...
Writing at 0x0006fa87 [============================> ] 97.8% 212992/217841 bytes...
Writing at 0x000717b0 [==============================] 100.0% 217841/217841 bytes...
Wrote 399280 bytes (217841 compressed) at 0x00010000 in 4.3 seconds (736.3 kbit/s).
Verifying written data...
Hash of data verified.
Il me semble avoir rencontré ce même comportement "il y a un certain temps" sur une autre carte microcontrôleur... ARDUINO sûrement car je n'utilisais que celles-là.