-
-
Notifications
You must be signed in to change notification settings - Fork 94
Configure UNO R4 WiFi to wait for post-touch port change #74
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
Conversation
The upload operation for the UNO R4 WiFi follows this sequence: 1. Perform a "1200 bps touch" to put the board into the mode where it can be flashed. 1. Invoke the `bossac` command that flashes the binary. 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 the `upload.wait_for_upload_port` property to `false` 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 was set to `false`. However, the board's port address can change under certain conditions and this caused the `bossac` command invocation to fail with a "No device found on ..." error because of the original port address being used in the generated command instead of the post-touch address. This spurious upload failure is avoided by changing the value of the `upload.wait_for_upload_port` property to `true`. Note that this does have the unfortunate side effect of introducing the post-touch wait delay in all uploads that do not produce a port address change.
However, the board's port address can change under certain conditions
That should only happen when the user is running a sketch that requires native USB I think.
For that particular use case, I'd prefer to force using the "manual" procedure (double tap on reset + select the "new" port manually before uploading)
We might think about a more sophisticated method based on the PID (that is different between a native USB and the ESP32 USB) but without harming the normal experience
For that particular use case, I'd prefer to force using the "manual" procedure
OK, that is reasonable. I will close this as declined. In its place, I have submitted proposals to document the required "manual" upload procedure:
- In the "Arduino UNO R4 WiFi USB HID" tutorial: Document special upload procedure in UNO R4 WiFi HID tutorial docs-content#1246
- In the Help Center article for the "
No device found on ..." upload error: Document UNO R4 WiFi-specific fix for "No device found on ..." upload error help-center-content#258
Create RTC_PeriodicExample.ino
Create RTC_PeriodicExample.ino Former-commit-id: 5bc4448
The upload operation for the UNO R4 WiFi follows this sequence:
bossaccommand 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_portproperty tofalsein 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_portproperty was set tofalse:ArduinoCore-renesas/boards.txt
Line 138 in e5ab698
However, the board's port address can change under certain conditions and this caused the
bossaccommand invocation to fail with a "No device found on ..." error because of the original port address being used in the generated command instead of the post-touch address (#73).This spurious upload failure is avoided by changing the value of the
upload.wait_for_upload_portproperty totrue.❗ Note that this does have the unfortunate side effect of introducing the 10 s post-touch wait delay in all uploads that do not produce a port address change. I don't have any idea about an alternative solution that would make uploads 100% reliable while also avoiding this inefficiency.
Fixes #73