Arduino Zero USB HID Broken and unusable Programing Port

[emergencyhamnet]

After three frustrating days I can finally get my Arduino Zero to move my mouse pointer. This has been a difficult transition from the UNO.
[1] The program port would not allow download, after some time thinking it was me and a lot more time searching forum posts I concluded I needed to roll back the SAMD to version 1.8.10 which fixed my issue.
[2] I could not get the USB to connect with the correct driver, it always came back with the Arduino Zero Driver. after a full day I have understood that the Device Description is read as Arduino Zero which is why Windows gives it that driver, it then fails to start so Windows disables it. I finally found the fix to that was to roll back to SAMD 1.6.21 from sometime back last November.
So, with that old software my board works.
Have to say that my love for community projects and Arduino has tarnished a bit becasue of this experience. To hear people say things like this was fixed 3-4 months ago but no new release yet, kind of disappoints me. I got the Zero for the debug and have to conclude it must not be a popular board. I know you guys do your best, but if I need to volunteer as a beta tester to make things better I will.
Full details of my findings at https://forum.arduino.cc/t/arduino-zero-is-buying-it-a-mistake/957425/11

[emergencyhamnet]

Update, not that I see anybody taking an interest.
There is no working debug in IDE 2 with SAMD 1.6.21 so I feel the board is a scam, perhaps the ATMEL STUDIO 6.2 will work, but what a mess guys,
Perhaps someone can tell me if the whole Arduino code base is community supported or if there is some commercial interest from those selling the official boards, If its only community, then I wish I had known that as I expected more and wanted to support the Arduino project buying official boards at a premium. Its not my nature to be mean, but my time has value and I really feel scammed buying this board.

[facchinm]

Hi @emergencyhamnet ,
sorry to hear that your experience was so disappointing.
In any case, we are here to help and try to fix the problems, so bear with me.

1. The Programming port uses openocd to upload sketches, but apart from that nothing changed on that side between cores 1.6.x and 1.8.x . If you could provide a verbose output of the upload phase (remember to select Arduino Zero (Programming Port) as board) while on core 1.8.12 it would be helpful to understand the root cause of the issue

2. Composite drivers have instead changed from 1.6.x to 1.8.x and Windows (particularly Windows7) has "some" issues in enumerating them correctly. If you are on Windows 7 the best thing to do is in fact reverting to 1.6.x (as you did), while Windows 10 has no problem while you uninstall the existing driver (the board will then enumerate correctly).

[per1234]

@facchinm item (1) in the problems you listed is the bug that has already been fixed by #655, but not released.

[facchinm]

My bad then, I'm going to release ASAP

[emergencyhamnet]

The "Bug" was fixed by going back to the old driver, understanding any other fix was beyond my pay grade but gong back lost me the debug port. For now I am using a Leonardo which has been flawless.
If it can be released, I would be really appreciative.

[per1234]

If it can be released, I would be really appreciative.

Already done @emergencyhamnet. Just use the Arduino IDE Boards Manager (Tools > Board > Boards Manager) to update your "Arduino SAMD (32-bits ARM Cortex-M0+) Boards" to 1.8.13. That will solve your problem [1].

---

I believe your [2] is #423, which is still open. facchinm provided a workaround there: #423 (comment)
However, from the discussion on the forum thread it sounds as though that did not work for you.

Which version of Windows are you using?

[emergencyhamnet]

I am running the latest windows 21H2 OS build 19044.1526 and the incorrect naming of the USB port went away when I went back to SAMD 1.6.21. I did post the Device Driver views and USBDeview captures in the forum.
It seems that using the Zero as a HID USB device is not a popular use case. If I can get it to work reliably it has the potential to get my design from two Arduino's to one because the extra processing power.
I am happy to do tests and provide dumps etc but you may have to explain what you need the first time as my experience with the IDE and Arduino is limited. Its been 30 years since I did any assembly style programing professionally.
Thanks a bunch for getting on the case.

[facchinm]

Thank your Stephen for the help!
One thing I would ask you to try is changing the value 0x100 in these two lines

ArduinoCore-samd/cores/arduino/USB/USBCore.cpp

Lines 88 to 89 in 3fd369e

	const DeviceDescriptor USB_DeviceDescriptorB = D_DEVICE(0xEF, 0x02, 0x01, 64, USB_VID, USB_PID, 0x100, IMANUFACTURER, IPRODUCT, ISERIAL, 1);
	const DeviceDescriptor USB_DeviceDescriptor = D_DEVICE(0x00, 0x00, 0x00, 64, USB_VID, USB_PID, 0x100, IMANUFACTURER, IPRODUCT, ISERIAL, 1);

to anything else, recompile and upload to check then if windows re-enumerates properly.
You can find the file in a path resembling C:\\Users\your_user_name\AppData\Local\Arduino15\packages\arduino\hardware\samd\1.8.13\cores\arduino\USB

[emergencyhamnet]

OK done some experimenting and have attached all I think might help.
I took a few goes to get back into using the Zero, when I started the Native port was Com 3 and programming Com4 (I had reset the Com numbers from my previous Zero testing because I was up to Com85 and didn't like that).
I did try the sw change and was not sure if it helped, I went back to the original software but by then my native port was up to Com6.
Sorry about that as it might have been relevant, not sure if the change was cached because I never saw any more port increases in all my following tests???
My formal tests were starting with original software, then changing it. I did not see any difference between modified and unmodified software.
The Zero did not program through the programming port, would not emulate a mouse, did not deliver serial data to the serial port I expected (the one it opens), but was consistent at delivering data to the programming port.
[1] I updated all software using Lib Manager to latest versions.
[2] I used the zero usb blink usbserial example, code
#include <Mouse.h>
const byte enablePin = 2;

void setup()
{

Serial.begin(9600);
// while ((!SerialUSB) && (millis() < 10000));
Serial.println(F("Just a test"));
pinMode(13, OUTPUT);
pinMode(enablePin, INPUT_PULLUP);
Mouse.begin();
}

void loop() {
Blink ();
Serial.println(F("Blink"));
Modulate ();
Serial.println(F("Modulate"));
}

void Blink () {
digitalWrite(13, HIGH); // turn the LED on (HIGH is the voltage level)
delay(1000); // wait for a second
digitalWrite(13, LOW); // turn the LED off by making the voltage LOW
delay(1000); // wait for a second
}

void Modulate () {
if (digitalRead(enablePin) == LOW) {
Mouse.move(0, 200);
delay(1000);
Mouse.move(0, -200);
delay(1000);
}
}
[3] Programing Port does not work, see dump of upload error in attached file
zero_usb_blink_pprograming_port.txt
[4] I used the native port which was Com 6, Com 4 was the programming port. It loaded, set a new COM 9. No serial data on COM 9, but serial data was on COM 4. Blink LED worked, and Zero's TX light did burst as expected. No serial mouse detected by the host so no mouse movement.
[5] Tried a reload, it failed, could not open COM 6 which was the native port, see dump file provided. It then re-loaded set COM 9 again but no serial data, still on COM4.
zero_usb_blink_second_reload_native_port.txt
[6] Continued to re-load correctly but all using Com9.
[7] Reset the card, Com 6 became the native port again, used it and it produced a similar error to [4] about being unable to open Com6, see
zero_usb_blink__reset_reload_native_port.txt
[8] Manually switch to Com9 and was able to re-load as before.
[9] Changed sw per instructions, set address to 0x010. Reset the card, was back to Com6 native, Com 4 program.
[10] Uploaded to Com6 same error as [4] unable to open Com6 manually changed that to Com9 and was able to reload and continue.
I have also


captured the Com ports for a reset zero and after the board is loaded with the sketch.

[per1234]

[3] Programing Port does not work, see dump of upload error in attached file
zero_usb_blink_pprograming_port.txt

From zero_usb_blink_pprograming_port.txt:

Arduino: 1.8.19 (Windows 10), Board: "Arduino Zero (Native USB Port)"

The upload failed because you had the wrong board selected from the Tools > Board menu in the Arduino IDE.
You must select Tools > Board > Arduino SAMD (32-bits ARM Cortex-M0+) Boards > Arduino Zero (Programming Port) in order to upload via the "Programming Port" on the Zero.

[emergencyhamnet]

Not so sir!! I used the programming port, you can see that by it trying Com4 which is and has been the programming port.
I just retried it, that message about native port com is real but only there on the programing port download, if I use the native port I do not see any similar message.
Does no one have a Zero there??

[per1234]

Please try this:

1. Use a USB cable to connect the "Programming Port" of your Arduino Zero board to your computer:
   
2. Select Tools > Board > Arduino SAMD (32-bits ARM Cortex-M0+) Boards > Arduino Zero (Programming Port) from the Arduino IDE menus.
   ❗❗❗❗❗ DO NOT select "Arduino Zero (Native USB Port)" from the menu ❗❗❗❗❗
3. Select the port labeled "(Arduino Zero (Programming Port)" from the Tools > Port menu in the Arduino IDE.
4. Select Sketch > Upload from the Arduino IDE menus.

[emergencyhamnet]

Look my friend, why do you assume I do not have a brain and have not figured out which is the programming port and which is the native port? I am embarrassed for you not understanding my last post.
It is clear from the dump that the device is trying to connect to Com4 and if you look at the device manager pictures you will see that is the programming port.
Just because the header in the dump says native port do not assume that it is connected to the native port. It is quite possible that the same message is an indication that the download program has not correctly switch to use the programming port.
I said there is no such message on the native port (I would have had to know that to be able to say things like the programming port does not work but the native port does?).

[emergencyhamnet]

OK I willingly eat some of my words. The programing port download does now work in the current core release.
The problem was me changing the download port but not selecting the second version of the Zero. Telling me to select the programing port was not quite right, I needed to select the correct zero board.
I guess I forgot that step having spent so long working on the other bord.
Apologies for my stupidity, but lesson learned to remind everybody to select both the board and the port whenever changing from native to programming ports.
Still no mouse bounce, Windows fails to find the correct driver and disables the port.

[richardhosking]

My sympathies to all here - have spent a couple of days fighting with an Arduino Zero and a HealthyPi3 which uses the same SAMD processor but does not have the Atmel EDBG USB programmer chip
Hopefully my experience will be helpful as this seems to be a common problem on the net but with few useful responses

Sequence of events - programmed both with sketches - they worked initially but then died - the HealthyPi is not even recognized as a USB device
The USBSerial port should not be used for programming for this reason
Sometimes the USB port can be seen but not always
The SAMD chip can apparently be erased with a USB stop and start at 1200 bits - I suspect I have erased the bootloader on both the Zero and HealthyPi

Solutions tried without success from posts on the net
Program both nativeUSB and programming ports on Zero - HealthyPi appears to only have the NativeUSB port
Correct board, port,programmer Atmel EDBC
Roll back SAMDboard package 1.8.3 to 1.6.21
Arduino IDE 1.8 to 2.0
Reset as upload starts
burn bootloader - failed
Nothing will upload to the board

Solved
Finally it appears that it is the old Linux USB permissions issue
lsusb produces
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 003: ID 046d:c31c Logitech, Inc. Keyboard K120
Bus 003 Device 002: ID 093a:2510 Pixart Imaging, Inc. Optical Mouse
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 022: ID 2341:804d Arduino SA Arduino Zero
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
for the NativeUSB port

and
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 003: ID 046d:c31c Logitech, Inc. Keyboard K120
Bus 003 Device 002: ID 093a:2510 Pixart Imaging, Inc. Optical Mouse
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 024: ID 03eb:2157 Atmel Corp. EDBG CMSIS-DAP
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
for the Zero programming port

The udev rules system is "powerful" which in my experience usually means cryptic and poorly documented unless you are an old Linux hack who doesnt mind reading man pages :)
Again there are lots of posts - many of them completely wrong

My solution:
using sudo gedit create a new file
(Note I have replaced # with // for comments - # does weird things to formatting here)

//udev rule to get the Arduino Zero and other boards to connect to USB ports properly
//save as /etc/udev/rules.d/arduino.rules
//execute as root in gedit
//Programming port in Arduino zero - Atmel EDBG chip
SUBSYSTEMS=="usb", ACTION=="add", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2157", GROUP="users", MODE="0666"
// Polulu USB driver board
SUBSYSTEMS=="usb", ACTION=="add", ATTRS{idVendor}=="1ffb", GROUP="users", MODE="0666"
//Arduino Zero SerialUSB port
SUBSYSTEMS=="usb", ACTION=="add", ATTRS{idVendor}=="2341", ATTRS{idProduct}=="804d", GROUP="users", MODE="0666"

test the new rules with something like
udevadm test /dev
this will read the various rules files
arduino.rules should be at the end

run
sudo udevadm control --reload
and the rules should be active

Burn the bootloader and "voila!" it worked
The Zero will now accept sketches

I will have to work out a JTAG interface solution for the HealthyPi3...