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.
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.
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.
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.
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.
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