amowry
October 20, 2022, 3:22pm
1
In previous versions of the IDE, it was possible to program devices that needed to be put into bootloader mode by pressing a button (i.e. a device with the CDC class turned off). The IDE would wait and show this output:
PORTS {} / {} => {}
PORTS {} / {} => {}
PORTS {} / {} => {}
PORTS {} / {} => {}
PORTS {} / {} => {}
The IDE 2.0 doesn't seem to wait at all-- it just immediately gives this error: "Failed uploading: no upload port provided". Is there any way to change this behavior? This seems like a shortcoming because some Arduinos like those based on 32U4 often have to be put into bootloader mode manually. Thanks!
Hi @amowry . This bug was fixed just today:
arduino:main ← per1234:upload-without-port-selection
opened 02:59AM - 18 Oct 22 UTC
### Motivation
It is common for a "port" to be used in some way during the proc… ess of uploading to a board. However, the array of Arduino boards is very diverse. Some of these do not produce a port and their upload method has no need for one.
For this reason, the IDE must allow the upload process to be initiated regardless of whether a port happens to be selected. During the addition of support for [user provided fields](https://arduino.github.io/arduino-cli/dev/platform-specification/#user-provided-fields) (https://github.com/arduino/arduino-ide/pull/550), an unwarranted assumption was made that all boards require a port selection for upload and this resulted in a regression that broke uploading for these boards. This regression was especially user unfriendly in that there was no response whatsoever from the IDE when the user attempted to initiate an upload under these conditions.
### Change description
Always initiate the upload process regardless of whether a port is selected. In cases where a port is required, the resulting error message returned by Arduino CLI or the upload tool will communicate the problem to the user.
### Other information
Fixes https://github.com/arduino/arduino-ide/issues/702
Fixes https://github.com/arduino/arduino-ide/issues/770
### Reviewer checklist
* [ ] PR addresses a single concern.
* [ ] The PR has no duplicates (please search among the [Pull Requests](https://github.com/arduino/arduino-ide/pulls) before creating one)
* [ ] PR title and description are properly filled.
* [ ] Docs have been added / updated (for bug fixes / features)
It will be in tomorrow's nightly build . Until then, the workaround is to select any port you have available. It doesn't matter what the port is.
You are welcome. I'm glad if I was able to be of assistance.
Regards,
You can always select a different port, e.g. COM1 or the port of a connected Uno/Nano/TTL-to-USB adapter. Start the upload with both boards connected, target will be the 32U4 based board, port the other board.
amowry
October 24, 2022, 7:59pm
6
The behavior seems to be the same in the most recent (20221024) nightly build. Has the fix not been added?
Thanks!
Hi @amowry . After reviewing the previous discussion, I see I was thinking about a different problem from the one you are experiencing. I apologize for any confusion I caused.
The bug I mentioned was that nothing at all happened after clicking the Upload button when no port was selected. There is a detailed description of that bug here:
opened 02:25PM - 24 Jan 22 UTC
closed 03:31PM - 20 Oct 22 UTC
conclusion: resolved
topic: code
type: imperfection
**Is your feature request related to a problem? Please describe.**
Compiling a … project for a Digispark works great, however, uploading doesn't work (it doesn't do anything if I hit upload). Presumably because the Digispark doesn't present a 'port' to upload to.
**Describe the solution you'd like**
I'd like to be able to upload a project when there's no port selected, for hardware that doesn't upload using a static port.
**Describe alternatives you've considered**
Uploading the .hex from CLI. It works, but would be nice if we could do it from the GUI, like we used to in Arduino 1.x
That bug has been fixed in the nightly build.
I see now that you are able to initiate the upload operation, but then getting an error message:
I can reproduce the problem and have submitted a bug report:
opened 01:21AM - 25 Oct 22 UTC
closed 10:42AM - 18 May 23 UTC
topic: code
type: imperfection
### Describe the problem
The primary microcontrollers of many Arduino boards … have USB capabilities (e.g., Leonardo, Micro, MKR). These boards often communicate directly between the primary microcontroller and PC rather than having a separate "bridge" interface chip that provides the USB capability needed to communicate with the computer (e.g., Uno, Mega).
Because the USB capabilities are implemented as part of the same program as the user's sketch code on these "native USB" boards, it is possible for the user's code to disable, interfere with, or break the USB communication with the computer. This is a common occurrence that should be expected as part of the experience of developing firmware for this type of board. That may be the expected outcome (e.g., putting the microcontroller to sleep) or an unexpected result of a bug. When this happens, the board no longer produces a USB CDC serial port. This can make it difficult to upload to the board since that port is used in the upload process (e.g., ["1200 bps touch"](https://arduino.github.io/arduino-cli/dev/platform-specification/#1200-bps-bootloader-reset)).
In order to facilitate the recovery from this "[soft bricked](https://en.wikipedia.org/wiki/Brick_(electronics)#Soft_brick)" state, some bootloaders have a feature where they run indefinitely on the second of two resets in quick succession (sometimes referred to as "[double-tap](https://docs.arduino.cc/tutorials/nano-33-ble-sense/cheat-sheet#forcing-bootloader)"). However, not all bootloaders have this capability. On the bootloaders without support for the "double-tap" mode, the bootloader runs only for a short time after a reset before timing out and exiting to the application. In this case it is necessary for the user to time the manual reset so that the upload process occurs while the bootloader is running. For a combined compile and upload operation, this is a bit tricky since the bootloader might time out during the compilation phase if the reset was done before starting the operation.
The standard recovery procedure for these boards, as documented [here](https://docs.arduino.cc/retired/getting-started-guides/ArduinoLeonardoMicro#uploading-code-to-the-leonardo-leonardo-eth-and-micro), is to wait until the tooling indicates the upload phase is starting, then manually reset the board. This worked fine in Arduino IDE 1.x because the "[wait for upload port](https://arduino.github.io/arduino-cli/dev/platform-specification/#1200-bps-bootloader-reset)" phase is triggered even when no port is selected. The appearance of the port produced by the bootloader running after the manual reset is detected during that phase and used for the upload. However, that "wait for upload port" phase is skipped entirely if no port is specified in the Arduino CLI upload command:
https://github.com/arduino/arduino-cli/blob/f23975438ca8ad6463fadf61e181c0bc03a20ae1/commands/upload/upload.go#L381-L383
This is the case in the upload command produced by Arduino IDE 2.x when no port is selected, as well as in `arduino-cli` command line commands which do not contain a `--port` flag.
For users of the command line, the most "correct" approach would be to do a manual reset while `arduino-cli board list --watch` is running to determine the address of the bootloader port, then specify that port via the `--port` flag (manually resetting the board during the upload phase as usual to cause the port to be available for the upload).
This is not possible for Arduino IDE 2.x users, leaving them with the workaround of selecting an arbitrary random serial port that happens to be present on their system in order to cause a serial port to be provided to Arduino CLI so that it will run the "wait for upload port" phase during the upload. Some users may not even have an available port to use for the workaround, and even for those who do have a port it is very hacky.
The final recourse would be to do a "Burn Bootloader" operation, not because there is any need to re-flash the bootloader, but because the operation also erases the problematic sketch application from the board. However, that is very complicated for the average user and also requires additional hardware they might not possess.
🐛 It is difficult or impossible for users to recover these boards from the "soft bricked" state.
### To reproduce
#### Equipment
Native USB board that does not have "double-tap" support:
- [Leonardo](https://store.arduino.cc/products/arduino-leonardo-with-headers)
- [Micro](https://store.arduino.cc/products/arduino-micro)
- [Yun](https://store.arduino.cc/products/arduino-yun-rev-2)
- I would guess any of the other boards that use Arduino's "caterina" bootloader, but I haven't checked others.
#### Steps
1. "Soft brick" your board by uploading this sketch:
⚠ This will put the board into a state that is slightly difficult to recover from.
```cpp
void setup() {
noInterrupts();
}
void loop() {}
```
1. Upload any sketch to the board without having a port selected.
1. Press and release the reset button on the board as soon as the upload process starts.
🐛 The upload fails even though the board was in bootloader mode:
```text
Error during Upload: Failed uploading: no upload port provided
```
### Expected behavior
It is possible for users to easily recover their boards from the "soft brick" state by following [the standard recovery procedure](https://docs.arduino.cc/retired/getting-started-guides/ArduinoLeonardoMicro#uploading-code-to-the-leonardo-leonardo-eth-and-micro).
### Arduino CLI version
f2397543
### Operating system
Windows, Ubuntu
### Operating system version
Windows 10, Ubuntu 20.04
### Additional context
As I mentioned in the introduction, it is already possible for command line users to accomplish a recovery in a fairly straightforward (though lengthy) manner. So this is mostly a problem for Arduino IDE 2.x users (and any other application that works in a similar manner). So it might be that the fix should be made in Arduino IDE 2.x rather than Arduino CLI.
For example, Arduino IDE 2.x could always pass the last selected port to Arduino CLI (it does not do this now), which would allow [the standard recovery procedure](https://docs.arduino.cc/retired/getting-started-guides/ArduinoLeonardoMicro#uploading-code-to-the-leonardo-leonardo-eth-and-micro) to be performed with the addition of the following steps at the start:
1. Press the reset button on the board.
1. Quickly select the port from the "Board Selector" or **Tools > Port**" menu.
I thought it worth first investigating whether there is a way for this to be handled by Arduino CLI without the requirement of a port selection, since that would allow the standard recovery procedure to continue to be used by the users of all modern Arduino development software. I was able to perform [the standard recovery procedure](https://docs.arduino.cc/retired/getting-started-guides/ArduinoLeonardoMicro#uploading-code-to-the-leonardo-leonardo-eth-and-micro) after simply removing the `&& port.Protocol == "serial"` from [`commands/upload/upload.go#L381`](https://github.com/arduino/arduino-cli/blob/f23975438ca8ad6463fadf61e181c0bc03a20ae1/commands/upload/upload.go#L381), but of course that conditional is there because the "1200 bps touch" process is specific to serial ports.
---
This is more relevant now because previously a bug in Arduino IDE 2.x (https://github.com/arduino/arduino-ide/issues/770) caused the Upload operation to not be initiated when no port was selected, so the Upload operation never got to the stage when the "`Failed uploading: no upload port provided`" error was returned by Arduino CLI during these recovery attempts.
---
Originally reported at https://forum.arduino.cc/t/ide-2-0-wont-program-arduinos-that-need-to-be-put-into-bootloader-mode/1044198
#### Additional reports
- https://forum.arduino.cc/t/arduino-2-1-0-breaks-stm32-hidbootloader-setup/1123374
### Issue checklist
- [X] I searched for previous reports in [the issue tracker](https://github.com/arduino/arduino-cli/issues?q=)
- [X] I verified the problem still occurs when using the [nightly build](https://arduino.github.io/arduino-cli/dev/installation/#nightly-builds)
- [X] My report contains all necessary details
Thanks so much for bringing this to our attention!
For now, please use the workaround provided by sterretje :
sterretje:
You can always select a different port, e.g. COM1 or the port of a connected Uno/Nano/TTL-to-USB adapter. Start the upload with both boards connected, target will be the 32U4 based board, port the other board.
I should add that, although not possible on the boards using the standard "caterina" bootloader of the Arduino Leonardo , Micro , Yun , etc., some 3rd party ATmega32U4-based boards such as the SparkFun Pro Micro (but not most Pro Micro clones) have an enhanced version of the bootloader that allows them to be put into a persistent bootloader mode by pressing and releasing the reset button twice quickly. You will then be able to select the port of the board and upload to that port via Arduino IDE 2.x.
This will be the easiest recovery method for the boards with a bootloader that supports it. You can learn about it here:
https://learn.sparkfun.com/tutorials/pro-micro--fio-v3-hookup-guide#ts-reset
amowry
October 25, 2022, 3:55pm
9
Thanks so much for looking into this and submitting a bug report. I mostly use a custom 32u4 board that I make that does support the double-tap, which puts it into bootloader mode for 8 seconds. I currently do that once before uploading, click upload, and then have to put it into bootloader mode a second time. It's not a big deal at all, but the behavior in the old IDE was ideal, where it didn't require a port to be selected ahead of time.
Post #5 gives a workaround.
Up till now, I only once had to use the reset trick on a Pro Micro 3.3V after burning a sketch using the board settings for a 5V Arduino Micro because I was too lazy to install the Sparkfun AVR boards package and too eager to start with it.
Not sure what you do wrong. I'm looking for examples so if it happens to you again, I would like to see the sketch that caused the problem.
amowry
October 25, 2022, 4:30pm
11
Don't get me wrong, I'm totally fine using a workaround, I just thought the developers would like to know that the behavior is different than the old IDE, which didn't require a port to be selected. It sounds like the difference in my case is that I'm using a device that has the CDC class turned off, so it normally doesn't have any open ports (it's a class-compliant MIDI device). Thus, I have to put it into bootloader mode to present any port at all. I don't think the sketch factors in, but here's the sketch I'm using: https://github.com/amowry/warbl/tree/master/warbl_firmware
1 Like
Ah, thanks for the explanation.
1 Like
system
April 23, 2023, 4:44pm
13
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.