I've done quite a bit of searching and haven't found much on this particular issue. I'm using an Arduino board for the first time, but not new to embedded controllers, or hardware, or software. I'm a long time developer, and due to schedule constraints, I chose to go with a pre-made dev. board. Due to some space constraints in my initial application, I chose the Arduino Nano 3.0.

For my application, I'm using just the bare Nano board as is with no hardware additions. While things were working well initially, I'm seeing what looks like one or two lockup condition occur during power up on the FTDI chip.

The Nano 3.0 is completely bus powered in my application (and with no other external hardware this should be fine.) The Nano is being connected to the USB port of another embedded device. That device has ported FTDI drivers, so it generally communicates very well with the Nano.

If the embedded device is powered up when I plug in the Nano, all is usually well. However, if the embedded device is completely off (as in no AC) when the nano is connected, and power is applied to the embedded device, the Nano usually has trouble. The processor always starts just fine and runs code, but the FT232RL part doesn't. 8 times out of 10, nothing appears to happen at the usb device. The micro is sending data to the ftdi, and there is no activity on the RX/TX LEDs. I've got the arduino serial data echoing out another serial port (newsoftserial), so I can see/observe the arduino traversing through its software properly. 2 times out of 10 the RX/TX lights are lit up brightly (very brightly) on power. SOMETIMES, the host device can bring the FTDI out of this state, the bright LEDS go off, and then back to normal operation; flickering with com port traffic. I assume that the Host is able to reset/init the ftdi device at the driver level in this case. Sometimes though, it fails and the LEDs stay lit. Either the host can't even see the ftdi connected, or it can't/doesn't reset it/init it properly in software.

The reset button on the Nano has no effect on the condition, and after studying the schematic, that makes sense. The processor restarts just fine on the reset button, but on the Nano there is no connection to the FTDI RESET# line. (it's a no connect). Maybe a little more troubling, on the NANO 3.0 board, the TEST pin of the FTDI part is also left no connect, even though the ftdi data sheet clearly calls for this to be grounded. And a perusal of the Mega or Diecimila or other Arduino board schematics all clearly ground the TEST pin. All of those designs also address the RESET pin in some way, but to be fair some/all of those boards are geared more toward external power. (Nano can still support external power, I know... I don't need/want it for this application).

Once in the lockup state, I have to disconnect/reconnect the usb cable to restore communication.

For usb bus power applications, the FTDI datasheet does show configurations with a no-connect on the reset line. And maybe FTDI has self sufficient internal circuitry for the reset pin, but I think any hardware designer that didn't need this pin would pull it/tie high, connect to an RC reset etc. We've all seen wondrous things occur during power-up/power-down. If you want something in a state at power up, you tie it that way.

Unfortunately in this case, there is no recourse on the Nano side of the fence for me to recover the condition. And yes, you may say that the responsibility is on the Host side of the interface. But it sure seems reasonable to have a way for the entire Nano board to be reset without pulling the connection, or at least for the arduino to be able to reset the ftdi device. Yes, I can certainly attempt to mod the Nano to include a connection to the ftdi reset pin (and I have access to the tools to do it), but given the very tight quarters and small pin pitch of the ft232rl that is going to be a challenge to say the least.

Granted, there may be some issue at the driver in the embedded host device. I don't currently have much visibility into the Host device; suffice to say its a black box for now. So I can't see if the the Host device doesn't even see/detect the FTDI in these failures, or if it is not properly resetting/initializing the device in software. But at least in hardware terms, aside from the fact that the power is coming from the usb port, the ftdi is a peripheral on the arduino board.

But the missing hardware connections (especially the TEST pin) are troubling to me. Certainly it is possible for the ftdi part to power up/float into a funky state with the test pin left floating.

Now it just occured to me that I also happen to have an FT232RL breakout board, so my next test will be to connect that to the host device, and see what happens on power-up. I can easily mod that board since fortunately all the pins of the ftdi are bonded out to headers.

Here's the update to this item: Using a separate FTDI breakout board, I repeated the same tests. The breakout board never locks up, always powers up with TX/RX LEDS lit (the CEbus pins must default this way on power up/after power on reset). The Host is always able to establish a USB link (once it starts running). This pretty much eliminates the Host and Host driver from the suspect list.

After examination of the FT232RL breakout board schematic, I found that this design correctly grounds the TEST pin on the RT232RL. The FT232RL RESET pin is a no connect on this design.

So on my Nano board, I shorted pins 26(TEST) and 25(AGND) of the FT232RL with a solder blob. It was delicate, but not impossible. After grounding the TEST pin in this fashion, the instability and lockups have disappeared.

The Nano FT232RL USB no longer locks up. I found that this solved another issue I was having, where the arduino wouldn't be detected by my PC (unknown usb device), depending upon what other circuitry/test equipment was connected to the Nano board.

With the TEST Pin left floating, it appears that most of the time when you hot plug the arduino, it has a tendency to come up ok (but not always). The fact that the power and ground connections are made relatively at the same time plays a role here. Alternatively, if you have the nano plugged into a Host device thats powered off (ground connection, but no power) and power is applied, the part probably goes into Test mode, or an undefined state, i.e, Test pin floats high.

So Nano users out there beware: you need to ground pin 26(TEST) on the FT232RL IC for the Nano 3.0 board (probably 2.x as well).

Thanks for posting that. I am currently working on a datalogger for my GSXR and after using Arduino Nano for a few days now. I was able to upload sketches and communicate via serial port through USB.

Now I have issues with the Nano being recognized by Windows 7. I have to plug it in atleast 15 different times to finally get the COM port to show in Arduino (Also using USB View). Even if I manage to get the Nano recognized it will no longer accept sketch uploads. So after seeing your post I decided to try and solder pins 25 and 26 on the FT232RL.

I was able to do that and test the connection between the pins with a continuity test and confirmed the solder blob was good. After doing that the issues I described above still persist.

Well thought you may have new info, otherwise I ewill keep researching.. seems to be a common issues with this Nano.

*Update* Contacted Gravitech tech support and told them the issue. They did acknowledge that shorting 26(TEST) and 25(AGND) is a solution. I told them the issues I was still encountering even after shorting those pins on the FT232RL.

He had me test using external power, with external power into VIN my computer recognized the Nano immediately after plugging the USB, I was also able to load a sketch now!

So now they are asking for the device back so they may perform repairs on it..

I don't have any direct experience with getting a windows 7 PC to recognize the Nano. My development platform PCs are still running good old Windows XP, but I have not had a single ounce of trouble since I shorted pins 26 and 25. I've made this modification to all of my Nanos now.

Gravitech never responded to my tech support emails and requests for help, so looks like you got further than me there. At least they acknowledge the issue, but would be nice to hear if they plan to address it. At the very least this would be is an easy rework fix for them to make at build time, much easier than trying to solder-bridge the pins with an iron.

The lockup problem is not occur on every system. Only about 2-3% of the user experience this problem. To make sure we fix this problem, since Sep. 2009, all of the Arduino Nano shipped with the Test pin (26) connected to ground. The schematic in product page on Gravitech website has been modified.

If you experience this problem, it can be fixed easily by solder a bridge between pin 26 and 25 of the FTDI chip. Or you can send it back to us and we'll fix it for free. All they have to pay is the postage cost. Please contact us at support@gravitech.us for more info or RMA#.