ser_open() : can’t set com-state for « \\.\COM4 changes Uno not detected SOLVED

Development Tools IDE 1.x
1

For a project, I built a prototype with all electrics, sensors, Lcd and displays, and code. It works as it should. Pins used from 2 to 13, A0, GND and +5V, on a UnoR3 card (called here “My Uno”), purchased as part of an Arduino starter kit that has given no trouble.
It runs with IDE Arduino 1.8.2.
The computer is Dell Inspiron 17R-5720 (+ docking station DisplayLink to multiply the number of USB ports and display on 2 screens). Inspiron has USB2, Docking has USB3. The OS is W7 professionnal 64 bits. During the problem described here, no changes were brought to the PC, no W7 update.

To turn the prototype into definitive form, I purchased another genuine Uno card (called here “Project Uno”). I plugged the brand new “Project Uno” in and W7 told me that a new driver was being installed. So far, so good.
However, the IDE did not upload the code and gave Error message AVRDUDE: ser_open() : can’t set com-state for « \.\COM4 ». I did not think, at that stage to collect more verbose detail; they are no longer accessible.

The comparison between the two Uno cards shows
« My Uno » « Project Uno »
Card type Arduino/Genuino Uno Arduino/Genuino Uno
VID 2A03 2341
PID 0043 0043
S/N 855 393 139 313 51B 021 E1 557 363 133 383 514 162 D1
Port Com3 Com4
Driver date 19/03/2015 24/11/2015
Driver version 1.1.1.0 1.2.3.0
Supplier Arduino srl Arduino LLC
Location 0 Port #0002. Hub#0001 0 Port #0002. Hub#0001
(Sorry, couldn't format this table properly)

After reading www.arduino.cc/en/Guide/Troubleshooting, Google search, forum posts, … I went through the following checks:

  • Unplug & re-plug card: no change
  • Try different USB port locations on PC: no change
  • Restart PC: no change
  • Reset Uno card: L Led flashes ok (bootloader is ok)
  • Temporarily de-activate antivirus: no change
  • Connect with another USB cable: no change
  • Check 5V and 3.3V power: ok
  • Execute IDE as Administrator: no change
  • De-activate DisplayLink & restart PC as stand-alone: no change
  • Connect to a port on docking station: no change. (I realized later that this is the first time it got plugged into USB3.)

“No change” means each check was made for both cards. “My Uno” always uploads, “Project Uno” always fails with same error message. This excludes any problem with electrical contacts, USB connectors, or cable.
All this leaves me with the same questions as when I started, and without direction.

Next, the problem changes: the “Project Uno” card is not even detected anymore by the computer: no dingdong sound when plugging, USB port does not show in W7 Control Panel\Device Manager (Gestionnaire de Périphériques in French), IDE Tools\Serial Port has gone grey.
I then tried plugging into another PC (with Windows XP, totally stand-alone to avoid risk of corruption of a critical program). Same No dingdong sound and USB port does not show anywhere with “Project Uno”. “My Uno”, however, is detected and tries to install driver.

The 16U2 chip seems to be regularly accused of being weak; but I never drew any current as the card has always been connected bare, with no output, and not powered by anything but the USB cable. It was never laid on an electrically conductive surface.

Has “ProjectUno” card developed a hardware problem, in addition to an initially suspected driver problem? I absolutely want to understand & correct; if not it will obviously happen again.
Are the differences of VID, driver version, driver date, … significant? If so, how should they be taken care of?
Has the card been damaged? If so, why? How can this, hardware or otherwise, be fixed?
Would a CH340 clone be better?
My thanks to anyone who would offer his help.

2

"original" UNO's should give the same VID & PID

The only reason for other than that may be if one uses a UNO with FTDI (older versions).
The chips near the USB port should preferably be both the same or you may need additional drivers (I prefer to avoid those offered by microsoft)

Clones have shown a marked robustness with the CH340/341 chip over the original boards.
There are a couple of downsides in that you have to select both the board and the port which you generally dont need to do with true boards.
There can also be some minor issues with loopback tests.

You can also in most cases use another Arduino to upload to one that may have slight issues (mostly bootloader ones)

3

I think that the problem is with the drivers. I suggest you to install and update all official drivers for Arduino which are given with the Arduino IDE.

4

Thank you for replying

  1. "My Uno" has chip marked
    16U2
    1602 PH
    A7XYDB

"Project Uno" has chip marked
16U2
1801H TH
1810 VP
If it is not genuine, then it is a very good imitation

  1. I went into the IDE at Tools\Board\Board Manager
    In Arduino AVR Boards by Arduino version 1.8.2.
    Selected IDE 1.8.2. + Update
    It took about five minutes to upload. See attached

  2. Then
    tried uploading to "My Uno": works without problem
    tried uploading to "Project Uno": same as before. Card is not even detected (no dingdong, nothing in Device manager, ...)

  3. Where else should I look for drivers? (Euh, uncorrupted, if possible!!)
    Should I upgrade IDE to latest (1.8.12) version? I would not want to confuse the issue even more by introducing new unknown factors

2020-06-08MAJPilotes.jpg
2020-06-08MAJPilotes.jpg804×460 83.7 KB

5

I just find it odd that two boards with the 16U2 are not asking for seperate COM ports.
What happens if you plug one in a check device manager then plug the other in also at the same time ?
You should ideally see two seperate COM ports.

Myself I prefer to avoid USB 3.0 ports as they have been shown to cause some issues with Arduino's and with other hardware too that may have been meant for USB 2.0
Here I use a decent powered USB 2.0 HUB to overcome USB 3.0 issues.

Certainly flashing the bootloader with the GOOD UNO sounds like a viable option to see if that fixes the issue.

6

Plugging "My Uno" into the PC produce the apparition of Ports(COM & LPT). See attached.
The properties of the port show a driver 6.1.7601.18247 (win7 sp1_gdr.180828-1532) supplied by Microsoft Corporation
Plugging "Project Uno" produces ... nothing. (Remember, it initially produced a connexion COM4, before it decided not to connect anymore)

Futher searching shows that VID2A03 ("My Uno") pertains to Arduino.org; the color of the card is dark greenish.
VID 2143 ("Project Uno") pertains to Arduino.org with a dark blueish color.
At the time of the dispute between the 2 sides of Arduino, there were apparently a lot of connexion problems. IDE appears to have been in the region of version 1.6.2. My IDE is version 1.8.2. and marked Arduino.cc. I would think all this dispute bu...it has been made obsolete by subsequent versions, including mine.
I would therefore assume both should work from the same IDE, same USB port or not.

But, discussing drivers seem futile so long as card remains not recognized by the PC. Is it not?
Sorry, I am just a mechanical engineer, no geek.

I haven't tried flashing the bootloader yet.

2020-06-08 DeviceManager.jpg
2020-06-08 DeviceManager.jpg394×648 85.7 KB

7

Mech eng / millwright here too by trade.

And thanks for reminding me about the dot org etc. as that makes much more sense.

Yep try pushing a new bootloader to it.
If that fails you may consider throwing it out.
Chasing some of this type issue is long winded and no guarantee of sucess.

8

Flashed the bootloader from the good Uno as suggested.
Quite cumbersome
At the end of the process, Avrdude comments: “done burning bootloader”. See image attached.
But Avrdude comments notwithstanding, the Error LED went on during the process ??

The card was unwired, and replugged bare into PC with USB cable:

  • L Led flashes 3 times (normal),
  • then L Led comes off, then comes gradually back on and remains so: the previously existing Blink program has obviously gone
  • No dingdong as before: the card remains not recognized by the PC.

Throw it away? Just like that?
Its not that I am tight with my money (the expense is not this big). But doing that without understanding why is not in my mode of operation.
How can I protect myself from this re-occuring, or purchasing the next 20 cards in useless condition

I can't write "solved" next to this!

Is there a way to flash the 16U2?

2020-06-09 Burned Bootloader.jpg
2020-06-09 Burned Bootloader.jpg1202×860 187 KB

9

I just did a "loopback" test.
At the stage when the card should be connected to the PC, ... well it does not connect

10

There are TWO ICSP headers on most official boards use the one neatest the 16U2 to flash that.
On some boards those dont have header pins so you may need to add some.

11

To flash the 16U2, I have tried the method shown in https://www.arduino.cc/en/Hacking/DFUProgramming8U2. I found that the Flip program can only work if Windows detects a USB port, which stage we are not even reaching. All the effort with Flip, including loadind or re-loading the missing libusb0.dll ... are therefore in vain.
But I am not prepared to give up.

The method in Intructables (http://www.instructables.com/id/How-to-Restore-the-Arduino-UNO-R3-ATmega16U2-Firmw/) goes through the ISCP connectors from a working Uno board used a programmer. So, it has a chance to work!
It requires creating a specific boards.txt file. I think I have understood how this is made up, but ...

My W7 (64 bits version) has two locations for the original boards.txt!! (The two files are different, but the content pertaining to Uno is identical).
One path is (I believe 64 bit path)
C\Users\Alain\AppData\Local\Arduino15\packages\arduino\hardware\avr\1.8.2\ boards.txt
The other path is (I believe 32 bit path)
C\ProgramFiles(x86)\Arduino\hardware\arduino\avr\boards.txt

Why are there two locations?
Which one is my system working from?
Should I duplicate the creation in both locations?

12

Let me say first: I have arrived at a solution.

After I have read again and again (several times) the method described in
http://www.instructables.com/id/How-to-Restore-the-Arduino-UNO-R3-ATmega16U2-Firmw/ :
I found I had misunderstood some instructions: the path to install the special files to "repair" the 16U2 is (under Windows 7-64) in My Documents. (Full path : "C:\Users\Alain\Documents\Arduino\hardware\custom\avr\bootloaders)

I first had several error reports when burning the bootloader, which I related to the instruction below in the c:\Users\AppDtata\Local...\platform.txt file.. Errors were "no such file or directory".

tools.avrdude.bootloader.pattern="{cmd.path}" "-C{config.path}" {bootloader.verbose} -p{build.mcu} -c{protocol} {program.extra_params} "-Uflash:w:{runtime.platform.path}/bootloaders/{bootloader.file}:i" -Ulock:w:{bootloader.lock_bits}:m.

(Don't ask me! Refer to Redirecting )
I copied its content into a file C:\Users\Alain\MyDocuments\Arduino\hardware\customs\avr\platform.local.txt and changed the / into \ in the above instruction ({runtime.platform.path}\bootloaders{bootloader.file}).
I also corrected the mispelling in "C:\Users\Alain\Documents\Arduino\hardware\custom\avr\bootloaders" directory path (initially bootloader when it should have been bootloaders).
I do not know which error caused the rejection of the code (quite possibly the missing final "s" in bootloaders), but the two fixes did the job. This also proves the platform.local.txt file was correctly located on C:\

At the end of this, the 16U2 flash upload was executed correctly, and the board (that I though was only destined to be thrown away) has been restored to full working order.

I only regret that I have not found what caused my problem in the first place.
But I have discovered in the repair process that the Reset and Ground pins of the ICSP2 connectors are very close to each other, and it would not take much to short them together. This would cause exactly that: 16U2 program is erased, and the board is not detected anymore by the PC.

My thanks to those who have helped me.

ICSP2.jpg