I left it unattended and running a sketch for about 2 hours, powered by the USB. When I came back, I plugged it off for a while, and when I plugged it back in again, it was no longer recognizable by Windows 7 ("Unkown Device"). I also tested on my notebook and it gave the same message : Unkown Device.
All my other Arduinos, FTDI breakout boards and PL2303 breakout boards are working fine. It is just this one that is misbehaving.
My suspicion is that the FTDI chip on it is gone to some digital heaven, because if I connect a FTDI breakout board to this nano (TX, RX, Vcc, GND and 10nF cap on DTR to RST), the Nano works fine: I can upload sketches to it and it works, although I am not using its on-board USB port. In short, the "Atmega" part of this Nano is fully functional.
I read about other ppl with a similar problem, and came to a topic pointing that the TEST pin on the FTDI chip being left floating could be the culprit, so I soldered it to GND, hoping this would fix my problem, but the problem persisted.
So, here are my questions to you:
is there any way to force a FTDI chip to "revive" ?
is it worth to scavenge a FTDI chip from another device (like cell phone cables, and usb-to-9-pin-serial adapters) to try and fix this board? This would be a very risky procedure, considering the size of the chip involved.
Well, I think my FTDI (which seems to be fake, BTW) is dead.
Under windows it is listed as "USB\UNKNOWN". Under Linux (OpenSuse 13.2, with Kernel 3.17.3), it won't even show in lsusb (a FTDI breakout board I have lists ok). BTW, I don't have any FTDI drivers on this machine, since I use it exclusively for web & MariaDB development.
In journalctl -f (the equivalent to dmesg or tail -f /var/log/messages), this is what I get when I plug in this Nano:
Jan 21 00:03:25 oppie kernel: usb 4-2: device descriptor read/64, error -71
Jan 21 00:03:25 oppie kernel: usb 4-2: device descriptor read/64, error -71
Jan 21 00:03:25 oppie kernel: usb 4-2: new full-speed USB device number 32 using uhci_hcd
Jan 21 00:03:26 oppie kernel: usb 4-2: device descriptor read/64, error -71
Jan 21 00:03:26 oppie kernel: usb 4-2: device descriptor read/64, error -71
Jan 21 00:03:26 oppie kernel: usb 4-2: new full-speed USB device number 33 using uhci_hcd
Jan 21 00:03:26 oppie kernel: usb 4-2: device not accepting address 33, error -71
Jan 21 00:03:26 oppie kernel: usb 4-2: new full-speed USB device number 34 using uhci_hcd
Jan 21 00:03:27 oppie kernel: usb 4-2: device not accepting address 34, error -71
Jan 21 00:03:27 oppie kernel: usb usb4-port2: unable to enumerate USB device
Regarding Linux vs. Windows and steering a bit offtopic: I like Windows, but I specially like what the Bill & Melinda Gates Foundation does regarding funding researches (mostly health related) all around the globe. I also like Linux, and use it quite a lot (mostly at work, 'though), but Bill Gates' Foundation is worthy or admiration.
Thanks for you time, ChiliTronix. Do you have anymore suggestions I might try?
Sure, if you can do surface mount part rework.
Might have better luck removing it and then connecting an external FTDI Basic type card to the appropriate pins of the Nano.
There is a python 2 script about somewhere which can detect a bricked fake, unbrick it and make it inbrickable but I can't find it at the moment.... It runs on Python2.
ChilliTronix:
There is a python 2 script about somewhere which can detect a bricked fake, unbrick it and make it inbrickable but I can't find it at the moment.... It runs on Python2.
I found the program that does it (not in .py, ' though). The problem, however, is that every single program I found that can unbrick a driver-bricked FTDI needs it to be recognized by Linux or Windows, even if its USB ID is 0000. I'd be happy if my FTDI was shown as 0000. The problem, like I posted before, is that the kernel doesn't even find an id for it.
CrossRoads:
Might have better luck removing it and then connecting an external FTDI Basic type card to the appropriate pins of the Nano.
I've been using an external FTDI breakout board, and directly connecting it to the Nano's appropriate pins. It works like that, but takes valuable space on the protoboard.
Could soldering the FTDI's TEST pin to GND have made it worse?
If you look at the Duemilanove schematic, you will see the Test pin is grounded.
I still use mine regularly (as recently as last night with FTDI 2.12.00 drivers under Win7Pro)
so I don't think that would be a problem.
FT232 spec also says "Puts the device into IC test mode. Must be tied to GND for normal operation, otherwise the device will appear to fail."
