-
-
Notifications
You must be signed in to change notification settings - Fork 79
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
Upload to UNO R4 WiFi fails when "1200 bps touch" causes port change #73
Comments
@per1234 - you might want to see this and the following posts: #62 (comment) |
Thanks for your suggestion @mjs513. The fault still occurs when uploading to the UNO R4 WiFi board with the 0.2.1-rc1 version of the firmware on its bridge module. |
@per1234 - thanks for the explanation - haven't run into an upload issue since installing the update but only been playing I2C libraries |
A potential fix for this problem has been identified. This involves changes to two software components:
#74 was previously rejected, but the reason for rejecting it (the introduction of a 10 s delay into uploads when the sketch is not using HID) would no longer be valid (at least for users who have the updated firmware) due to the change to the firmware. Those with the older version of the firmware would still be subject to the increased upload durations, but I think this is less problematic when a remedy for the inconvenience is readily available. |
For whatever reason disconnecting my Samsung Galaxy Buds Bluetooth headphones is the only solution to this issue 😃 |
Describe the problem
The upload operation for the UNO R4 WiFi follows this sequence:
bossac
command that flashes the binary to the board.It is common for the address of the board port to change after the "1200 bps touch" step and so the Arduino development tools have a system for detecting the post-touch address and using that address when the upload command is generated from the "pattern" defined for the board in
platform.txt
. That system involves a post-touch wait to watch for the new port to appear before eventually timing out and resorting to the fallback behavior of using the original address to the upload pattern if no address change was detected. Since some boards will never produce a post-touch address change (meaning the post-touch wait step would only cause an unnecessary delay in the upload operation) it is possible to configure the board to skip the wait step by setting theupload.wait_for_upload_port
property tofalse
in the board definition.The assumption was made that the address of the UNO R4 WiFi board's port will never experience a post-touch address change, so its
upload.wait_for_upload_port
property is set tofalse
. However, the address can change under certain conditions and this causes thebossac
command invocation to fail with a "No device found on ...
" error because the original port address is used in the generated command instead of the post-touch address.To reproduce
Arduino IDE
the upload should be successful as long as the board isn't already running a problematic sketch.
🐛 The upload fails:
Arduino CLI
Setup
Demo
Expected behavior
Correct port address is always used in the upload command.
Project version
e5ab698
Operating system
Operating system version
Additional context
For the sake of simplicity, I used The the low level "HID" library in the demonstration sketch, but that is not commonly used in real world sketches. However, it is common to use the "Keyboard" or "Mouse" libraries, which have a dependency on the "HID" library and are documented as supported for use with the UNO R4 WiFi:
https://docs.arduino.cc/tutorials/uno-r4-wifi/usb-hid
The fault will also occur when using either of those libraries in a sketch:
Originally reported at https://forum.arduino.cc/t/failed-uploading-after-upload-usb-hid-example/1151778
Workaround
You should now see the "L" LED pulsing.
❗ The double reset you did in step (3) can cause the port number of the board to change, so don't assume you already have the correct port selected.
The text was updated successfully, but these errors were encountered: