That makes perfect sense NOW, after I’d spent hours screwing around with /dev/ttyUSB0 including ‘sudo chmod 666 /dev/ttyUSB0’ long before figuring out that this flashing method uses low level USB device control. The current documentation( https://docs.arduino.cc/tutorials/uno-q/update-image/ ) is lousy and states nothing about setting up a udev rule and then running ‘sudo udevadm trigger’ afterwards.
sudo vi /etc/udev/rules.d/50-embedded_devices.rules:
# Arduino UNO Q
SUBSYSTEM=="usb", ATTR{idVendor}=="05c6", ATTR{idProduct}=="9008", MODE="0666"
As I mentioned previously, it even incorrectly states to traverse to a MacOS named directory to run the arduino-flasher-cli command.
Linux
Navigate to the unzipped folder (e.g.
arduino-flasher-cli-x.x.x-darwin-arm64
), and run the following command:
FWIW, I removed the black listing of qcserial, rebooted and run the flasher as normal UserID and it failed as expected with opening the device. While it was still running and failing I created the udev rule and ran ‘sudo udevadm trigger’ and the flashing succeeded. So unless you all know of other reasons to black list qcserial, it’s likely not needed as it wasn’t needed on my Kubuntu 24.04 system which was “locking” the device by loading qcserial kernel module.
As you saw, I hit this problem over 2 weeks ago, created a github issue and got no action but a bug assignment so I started trying to debug the issue myself and found out that qdl’s “–debug” command was worthless but in that process figured out the problem wasn’t with /dev/ttyUSB0 it was lower than that. BTW, you’all are far more responsive here and I appreciate that.
Thanks for pointing this out. The script at the link I shared in my previous reply is from a proposal to add configuration of the required udev rule to the "Arduino UNO Q Board" platform. It does not currently add the rule that is needed to have the necessary permissions for the device produced by the board when it is in the "EDL mode" used when flashing the image. I requested that rule be added to the script:
Ya, you’re definition of “bricked” is not accurate but would be more accurate had to said you think it is ‘soft bricked’. You might not have had the communications with it that you expected but it was not turned into a worthless, unusable, unfix-able lump equivalent to a brick. A properly completed OS flashing would make it usable again. Semantics and maybe it’s just me since I have a hardware background( not just using hardware, but developing and repairing hardware ) so when someone says their device is “bricked” then there’s no coming back and your device has started working again.
I have no idea or care to understand how connecting over a network is relevant to if the device has been “bricked”.
Ah, I did not feel like going down the root system of what the heck Arduino Core Zephyr was since it had a different USB idProduct and idDevice numbers. I just used the rule mentioned as an example which was easier to copy/paste than create it manually. Looking at your pull request I now see you do cover the EDL USB device ids. Nice.
And I had learned of “EDL mode” from my run-in at the qdl packaging github repository issue which shed light on what was going on during flashing. It should have dawned on me to look at the low level USB device privileges since checking /dev/ttyUSB0 was the very first thing I did when I ran into this problem 2 weeks ago.
I have been doing hardware since I was 14, I am now 74, so I know a Dead Parrot when I see one. I have worked both in academia and in industry.
And written more hardware articles in computer magazine than I can count, but it is well over 400 now. Plus I have had 6 books commissioned and published.
Thanks for bringing this to our attention. I submitted a formal report on your behalf to the team at Arduino responsible for maintaining this documentation.
I apologize for any confusion that was caused by this error.
When did I say that? You might have misread a post here.
For your information I am in the process of sending the "bricked" Arduino Q back to the Arduino store for examination, to see if they can revive it, using tools or techniques that I do not have.
Sometimes it’s easier to just send the customer another unit and the fact that the system still boots a new EDL flash of the OS should do the trick and will be sold as refurbed.