You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Normally the Arduino IDE does the 1200bps_touch to jump into bootloader, which initializes the stm32 USB DFU and then the IDE passes to the ST-DFU-tools.
If the stm32 is already in the bootloader mode and for any reason, the Serial monitor is opened and the board is disconnected then the port still selected in the menu and in this case, the 1200 touch failed and the upload is ended. I think it should only report that the COM port is not found and try to upload anyway.
Hm, interesting point. I wonder how to solve this. An obvious way would be for the Arduino IDE to just skip the touch and upload anyway. However, for the original usecase, e.g. Arduino Leonardo or Zero, this is not really sensible, since the bootloader also communicates through serial, so if there is no serial port, there is no point in continuing. Maybe a new option for the IDE could help here (something like optional_1200bps_touch or so)?
A related observation is that when a Leonardo is already in bootloader mode, there is also no point in doing the 1200baud touch, but the IDE still does it (and it's not harmful either). But conceptually, it would be better if the IDE would actually detect that the board is already in bootloader mode (maybe based on USB id, but that might not actually be different for these boards, unlike the STM32 ROM bootloader which does have a different ID). If the IDE would support detecting it is in bootloader mode already, the STM32 upload could maybe profit from that to solve this problem too.
Even better would be if the IDE could detect and allow selecting USB devices even without serial port, based on USB ids, and then pass that info to dfu-util to let that handle the auto-reset (without the 1200baud touch being needed). This is actually already an option when you have just a single device that is already in bootloader mode, then dfu-util will just use it (with the boards.txt snippets I posted above), but that might not be superfriendly (you'd have to switch the programmer after manually resetting it).
I think this is indeed a good proposal and I wanted to tackle it sooner or later. All 1200bps boards change at least the USB PID as far as I know, so it would make sense to check if the bootloader PID is already "visible" before touching the port (and eventually targeting that one even if it's not selected by the user). @per1234 does it make sense to move the issue to arduino-cli repo since the development of new functionalities is going on there?
Normally the Arduino IDE does the 1200bps_touch to jump into bootloader, which initializes the stm32 USB DFU and then the IDE passes to the ST-DFU-tools.
If the stm32 is already in the bootloader mode and for any reason, the Serial monitor is opened and the board is disconnected then the port still selected in the menu and in this case, the 1200 touch failed and the upload is ended. I think it should only report that the COM port is not found and try to upload anyway.
Originally posted by @fpistm in stm32duino/Arduino_Core_STM32#710 (comment)
suggestion
Hm, interesting point. I wonder how to solve this. An obvious way would be for the Arduino IDE to just skip the touch and upload anyway. However, for the original usecase, e.g. Arduino Leonardo or Zero, this is not really sensible, since the bootloader also communicates through serial, so if there is no serial port, there is no point in continuing. Maybe a new option for the IDE could help here (something like
optional_1200bps_touch
or so)?A related observation is that when a Leonardo is already in bootloader mode, there is also no point in doing the 1200baud touch, but the IDE still does it (and it's not harmful either). But conceptually, it would be better if the IDE would actually detect that the board is already in bootloader mode (maybe based on USB id, but that might not actually be different for these boards, unlike the STM32 ROM bootloader which does have a different ID). If the IDE would support detecting it is in bootloader mode already, the STM32 upload could maybe profit from that to solve this problem too.
Even better would be if the IDE could detect and allow selecting USB devices even without serial port, based on USB ids, and then pass that info to dfu-util to let that handle the auto-reset (without the 1200baud touch being needed). This is actually already an option when you have just a single device that is already in bootloader mode, then dfu-util will just use it (with the
boards.txt
snippets I posted above), but that might not be superfriendly (you'd have to switch the programmer after manually resetting it).Originally posted by @matthijskooijman in stm32duino/Arduino_Core_STM32#710 (comment)
The text was updated successfully, but these errors were encountered: