Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

issue with the upload.use_1200bps_touch=true #1083

Open
rohitsam opened this issue Nov 22, 2020 · 3 comments
Open

issue with the upload.use_1200bps_touch=true #1083

rohitsam opened this issue Nov 22, 2020 · 3 comments
Labels
topic: code Related to content of the project itself type: enhancement Proposed improvement

Comments

@rohitsam
Copy link

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)

@facchinm
Copy link
Member

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?

@per1234
Copy link
Contributor

per1234 commented Nov 23, 2020

does it make sense to move the issue to arduino-cli repo since the development of new functionalities is going on there?

I think so. Transferring now.

@per1234 per1234 transferred this issue from arduino/Arduino Nov 23, 2020
@per1234 per1234 reopened this Mar 30, 2021
@liucy427
Copy link

I am using this board of Leonardo, the version is 0.18.1, how do you deal with it?Have you solved the problem @facchinm @rohitsam

@per1234 per1234 added the topic: code Related to content of the project itself label Apr 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
topic: code Related to content of the project itself type: enhancement Proposed improvement
Projects
None yet
Development

No branches or pull requests

6 participants