Arduino 2.1.0 breaks STM32 HIDBootloader setup

Somewhere between 1.8.57.0 and 2.1.0, Arduino seems to have introduced a check in the IDE to make sure that a serial port has been specified for upload. While this might be a useful check for some board defs, there needs to be a way for users to suppress this check. For one thing, this check prevents the initial setup of the HIDBootloader for STM32. I didn't find anything obvious from searching through forums, issues or the rest of the internet. There doesn't seem to be a way to suppress this check, although there may be a workaround so long as you have some other USB-serial device lying around that won't mind too much if it's DTR line gets toggled. I'm considering logging an issue for this, but posting here first to make sure I'm not missing something.

When initially setting up a BluePill or other STM32 based board with the HIDBootloader, you first program the bootloader using something like STM32CubeProgrammer, then you switch over to something like Arduino IDE and upload a sketch. This first upload does not require a serial port. The reason is that uploads using HIDBootloader 2.2 don't use serial uploads. They use an HID USB device defined on the STM32 by the bootloader and this is the mode it is already in when first programmed with the bootloader. It doesn't create a USB serial device until after a successful upload. Subsequent uploads after the first do specify the serial port, but only so the upload software can toggle the DTR to tell the bootloader to revert from USB-Serial to USB-HID in preparation to receive a new upload. In Arduino 1.8.57, this worked fine. You didn't need to specify a serial port in Arduino IDE and it would still initiate the upload, HID-Flash would find the [1209:BEBA] device and upload. Afterwards, a USB-Serial device is created on the STM32 for serial comms. For subsequent uploads you do need to provide this to Arduino so it can do the aforementioned DTR toggle, but for the very first upload after a newly programmed bootloader you don't need a port and any port you specify won't be used.

One workaround for this is to plug in something else - anything else - that defines a USB-serial device and specify that port to Arduino. So long as toggling DTR won't do anything weird to that device that at least allows Arduino to pass this port check and initiate the upload. The upload toggles the DTR and then finds the STM32-HID device that was already there and does the upload there instead. The one caveat to that is that this device shouldn't be an STM32 already programmed with HIDBootloader, because toggling DTR on that would tell it to revert to an HID device and then who knows where your upload goes.

There should be some way for uploads to proceed without specifying a serial port for cases like this where the serial port is not used and users may not have some other device lying around to fake it past this check.

Here's a screenshot trying to do the initial upload without some other dummy serial device available:

Here's the exact same Blue Pill board 30 seconds later with a Seeduino Xiao plugged in as COM6 as a dummy device. The upload went to the Blue Pill as required, not to the Seeeduino Xiao.

Hi @brettski74. This regression is tracked by the Arduino developers here:

That issue focuses on one specific use case that is a bit different from the one you mention, but they are both affected by the same underlying limitation in the new upload system, where the upload process is failed if no port is available to perform the "1200 bps touch" on.

If you have a GitHub account, you can subscribe to that issue to get notifications of any new developments related to this subject.

1 Like

I'm not familiar with it and I'm not sure if this is going to help.

Maybe you can use a generic port? E.g. Windows installations often have a COM1.

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.