Hello - for several months now I have seen a consistent issue with platformio which has been driving me nuts, and I’ve sort of just figured out how to sometimes resolve it.
Working with various ESP32 dev boards, the same thing happens with all of them.
In vscode, clean/build/upload => at the end of the upload, I notice this statement:
Hard resetting via RTS pin…
With the device manager open, I can see often that the COM port is switched for several seconds on re-initialisation of the board.
So if previously the serial monitor was on say COM7, then after the upload, the device manager will say COM3. With the serial monitor either set to Auto or COM7, the entire execution on the board is effectively stopped.
If I close the serial monitor, switch to COM3 then reopen the serial monitor, and then very quickly change the IDE port selection to Auto, the uploaded solution will come back to life.
I’m almost happy to finally see all of this and figure out how to overcome it, but clearly this is not the best. The issue clearly lies with the absolutely horrendous implementation by Microsoft with switching COM ports, but I would hope that the IDE port setting of Auto would be able to overcome this. Perhaps the Auto setting has a bug?
If anyone else knows how to stop this from happening, that would be amazing, because I had just about given up on platformio and I really want to keep using it for all the benefits it has compared to something like Arduino IDE etc.
Cheers
To clarify: This happens only for those ESP32 boards for which the USB port of the board is connected directly to the ESP32’s hardware USB peripheral, right? This should never ever happen with e.g. a ESP32 board where the USB-to-Serial is implemented by a static CH340 or CP2102, which shouldn’t just “eject” and reappear as a different board. But for e.g. for ESP32-S2, S3, C3 and boards using those ESP chips as the USB-to-serial converter directly, that can happen.
Hey, this is on a TinyS3 from Unexpected Maker - I’ll ask Seon to clarify the implementation as this happens on all of those boards.
The schematic of that board is open source, so the truth is already available.
https://github.com/UnexpectedMaker/esp32s3/blob/main/schematics/schematic-tinys3.pdf
And yes, the D+ and D- of the USB port go directly to the ESP32S3, so you’re exactly in the case that the board resets and might show up again with a different USB COM port.
So what you’re observing is that, after you upload to say COM3, the board reappears on COM7, and PlatformIO in the “Auto” upload port then tries to still open COM3 instead of COM7?
Hey thanks for your messages.
Looking into it, I have a strong hunch that it is platformio that is the bug here.
Firstly, this does not happen with the arduino IDE. The esptool is stateless, so it does not retain any COM values.
platformio appears to search for the USB-Serial/JTAG and that action is what causes the COM change during the upload cycle - in my case COM7 is that interface while the board USB-CDC is COM3.
This command in platformio - Hard resetting via RTS pin… - is actually not working and is the bug.
A correct reset will cause the bootloader ROM firmware to identify the CDC COM port back to COM3 - but because the board does not reset correctly, it does not, and so everything remains in COM7.
platformio immediately launches the serial which is attempting to interface over COM7, which will not work.
A push on the reset button connects back to COM3 - restarting the serial monitor unlocks the firmware pause state and it will start to run correctly.
I also added in my case this command to the ino file:
upload_port = COM[37]
monitor_port = COM[37]
So now COM3 and COM7 are forced. The pain is that I need to press that reset button every time now - first world problems I guess, but a problem none the less.
Fixing the reset call after upload will solve this issue.
Do you have the same CDC and USB MODE settings in ArduinoIDE as you have in PlatformIO?
(It’s 100% not a PlatformIO thing)
This sounds like once the upload port has been identified, it tries to do a “1200bps COM port touch”, which is a special signal to the firmware running on the ESP32 to reboot into bootloader mode. This behavior is enabled for lots of boards, but also configurable (board_upload.use_1200bps_touch = no in platformio.ini).
There are indeed different methods of resets available.
What does the Arduino IDE do here? Please share the esptool.py invocation that the Arduino IDE does. (File → Preferences → Verbose output during Upload, then a regular upload).
Equally, you can see what upload command PlatformIO uses exactly with project tasks → Advanced → Verbose Upload.
This behavior might just be a misconfigured default value in regards to the upload strategy and reset method.
Hi Max, thanks for the response. Apologies to @sivar2311 for my tardy response, but I’ve been ill for the past week.
I had a chat with Seon from Unexpected Maker about this, and his thinking is:
The issue is inside the pioarduino ESP32 Arduino Core version - not in PlatformIO
By the sounds of it, there are issues between different folks in different areas of the stack that enables the packaging, so I really don’t want to get involved with anything like that, or causing any more issues.
I guess like most folks, we just want a solution.
At the moment, I at least understand what is happening on my side and have a reasonable if not clunky solution. So perhaps I will mark this as closed and keep an eye out for the day when everyone plays nice and we can all just get on with building stuff.
Thanks to all of the people that make platformIO - I really do appreciate the effort that goes into making the software.