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.