Things like Arduino Uno clone boards that have CH340 chips on them instead of the ATMega16U2 as USB-UART bridge should be broken too (no 1A86:7523 HWID in uno.json).
The STM32 platform should be really broken too if it uses HWIDs to identify the serial port because the generic boards like platform-ststm32/genericSTM32F103C8.json at develop · platformio/platform-ststm32 · GitHub dictate HWIDs from the LeafLabs USB DFU bootloader that surely not everyone is using with those boards. (Think e.g.: just flash via STLink and monitor via some USB UART adapter)
I also personally ran into this problem with my platform-raspberrypi implementation when wanting to treat my Raspberry Pi Pico board as an Adafruit Feather RP2040 board (needed for some testing), PlatformIO stopped being able to monitor since it had the HWID mismatch – though I guess I could correct this in my board files.
I still have the opinion that the HWIDs should be seen as a “hint” or “priority choice”, not as a hard “if your HWID is not there we refuse to do anything”.
The goal of that refactoring was to improve situations when multiple boards are connected to the machine and PlatformIO picked the wrong port. Also, if HWID field is declared, PlatformIO will wait for the board following the default timeout. This also solves problems with boards that have a special bootloader.
How to solve the issue when a user tries to -t upload -t monitor and the board is not ready after uploading? That was the problem when we pick the wrong port (any serial port).
Does it look like a board definition problem? I prefer the declarative approach. If we receive a lot of complaints, it makes sense to revert back to the recent changes.
Do you have any ideas on how to improve this code?
A device can have multiple HWID sorted in most to least suitable for it.
A HWID is a combination of bus type, manufacturer, and device identifier. 1 or 2 hwid could be defined in platformio.ini superseded the default HWID declared by core platformio. in this case core used default in nothing is defined. if not defined and doesn’t work , use the HWID defined in platformio.ini. if also mean that HWID can be clear by definition in platformio.ini in case of there is no HWID identified.
It should fall back on the generic port finding (the behavior of PIO Core <6.1). You can ignore " TimeoutError: Could not automatically find serial port for the NodeMCU 1".
With this version of PlatformIO I can’t upload nothing to my Geeetech i3 ProB with GT2560.
Core 6.1.0* ·* Home 3.4.2
The last firmware update that I made without any problems was on 24.06.2022… Yesterday I spend 6 hours trying to upload the new firmware (because I changed many hardware things), but unsuccesfully.
I meant to open a CLI as I have linked above and execute pio upgrade --dev in it. The regular “Upgrade PlatformIO core” will “only” give you the last stable version, I want to check development core behavior. Can you check that?
If that does not work, please add
upload_port = COM4
to the platformio.ini but replace COM4 with the actual COM port where your board is connected (see Windows device manager → Ports)