Cannot detect UNO USB port

I have five Arduinos that have stopped working.

First, I run Linux (Ubuntu or Centos 7) and I have another UNO that works fine.

Three of the UNOs are not detected by the Operating System. All three are using the CH3400G chip, but I have another that also uses that chip and it is recognized just fine so the driver is not the issue.

The lsusb command shows:

Before connection

Bus 002 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 03f0:231d Hewlett-Packard Broadcom 2070 Bluetooth Combo
Bus 001 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

After Connection

Bus 002 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 03f0:231d Hewlett-Packard Broadcom 2070 Bluetooth Combo
Bus 001 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

No difference seen.

I have run dmesg before and after attaching the UNOs and here are the lines that show up after the connection.

usb 2-1-port3: Cannot enable. Maybe the USB cable is bad?
usb 2-1-port3: Cannot enable. Maybe the USB cable is bad?
usb 2-1-port3: attempt power cycle
usb 2-1-port3: Cannot enable. Maybe the USB cable is bad?

The cable is fine, it works with other UNOs.

So my guess is that the chip may be bad, or may have some other issue. I would like to resurrect these three boards, but don't hold out much hope.

If the USB port cannot be salvaged, can these boards be programmed by another UNO much the same as a UNO can be used to program a NANO?

Any suggestions or pointers to other articles would be appreciated.

ov10fac:
can these boards be programmed by another UNO much the same as a UNO can be used to program a NANO?

Yes, as I already said in your other thread:
http://forum.arduino.cc/index.php?topic=577745

You could also connect a USB to TTL serial adapter to pins 0 and 1 to continue programming the boards over serial. The advantage is that you will also be able to use this connection for serial communication with your computer, debug output for example.

Of course, none of that will work if there was a "magic smoke" incident that destroyed the ATmega328P in addition to the CH340.

pert:
Yes, as I already said in your other thread:
Uno to Uno bootloader - Microcontrollers - Arduino Forum

You could also connect a USB to TTL serial adapter to pins 0 and 1 to continue programming the boards over serial. The advantage is that you will also be able to use this connection for serial communication with your computer, debug output for example.

Of course, none of that will work if there was a "magic smoke" incident that destroyed the ATmega328P in addition to the CH340.

Hadn't thought of that. I'll pick up a serial USB adapter and give it a try. As for "magic smoke" nothing like that was observed, however stranger things have happened.

Thanks for the idea.

OK,
My FTD1232 USB to serial chip arrived today. I can find a few articles on how to connect them to the mini, but nothing on how to connect to the UNO. I want to use this new FTD1232 to program the UNO with bad USB ports.

Thanks for any help.

| FTDI | | | Uno |
| - | - | - |
| ---- | | | ---- |
| RX | | | TX |
| TX | | | RX |
| VCC | | | 5V |
| GND | | | GND |

If you are powering the Uno separately then don't connect the VCC pin.

If your FTDI adapter has configurable power levels, make sure it's set to 5 V.

The above connections will not provide an auto-reset circuit so you will need to press the reset button on the Uno at just the right time in the upload (just as the upload starts but after compilation is finished. You can turn on verbose output during upload in File > Preferences to get an idea of the progress of the upload. If you want the auto-reset behavior like when you used the Uno normally, then you need to connect the DTR pin on the FTDI to the reset pin on the Uno via a 0.1 uF capacitor.

pert:
| FTDI | | | Uno |
| - | - | - |
| ---- | | | ---- |
| RX | | | TX |
| TX | | | RX |
| VCC | | | 5V |
| GND | | | GND |

If you are powering the Uno separately then don't connect the VCC pin.

If your FTDI adapter has configurable power levels, make sure it's set to 5 V.

The above connections will not provide an auto-reset circuit so you will need to press the reset button on the Uno at just the right time in the upload (just as the upload starts but after compilation is finished. You can turn on verbose output during upload in File > Preferences to get an idea of the progress of the upload. If you want the auto-reset behavior like when you used the Uno normally, then you need to connect the DTR pin on the FTDI to the reset pin on the Uno via a 0.1 uF capacitor.

Many thanks. I followed your advice and uploaded blink with what seems to be no problems. Here is the output from the upload process:

Starting upload
Uploading project "Blink" with "AVRDUDE"
Starting reset using DTR toggle process
Continuing to use "/dev/ttyUSB0"
Ending reset

Launching: /home/jwright/opt/sloeber//arduinoPlugin/packages/arduino/tools/avrdude/6.3.0-arduino14/bin/avrdude -C/home/jwright/opt/sloeber//arduinoPlugin/packages/arduino/tools/avrdude/6.3.0-arduino14/etc/avrdude.conf -patmega328p -carduino -P/dev/ttyUSB0 -b115200 -D -Uflash:w:/home/jwright/Documents/sloeber-workspace/Blink/Release/Blink.hex:i
Output:

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e950f (probably m328p)
avrdude: reading input file "/home/jwright/Documents/sloeber-workspace/Blink/Release/Blink.hex"
avrdude: writing flash (930 bytes):

Writing | ################################################## | 100% 0.38s

avrdude: 930 bytes of flash written
avrdude: verifying flash memory against /home/jwright/Documents/sloeber-workspace/Blink/Release/Blink.hex:
avrdude: load data flash data from input file /home/jwright/Documents/sloeber-workspace/Blink/Release/Blink.hex:
avrdude: input file /home/jwright/Documents/sloeber-workspace/Blink/Release/Blink.hex contains 930 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 0.35s

avrdude: verifying ...
avrdude: 930 bytes of flash verified

avrdude done. Thank you.

The execution of command "avrdude" is done.

Thanks.

Congratulations! I'm glad if I was able to be of some assistance.
Per