Go Down

Topic: Why does PuTTY hang my Duemilanove? (Read 1 time) previous topic - next topic

3dprinter

I have an (older) Arduino Duemilanove and an Arduino UNO. The older uses the FTDI the newer the 8U2. My host systems are a Win XP and a Win7(64bit.) Drivers have been reintstalled/updated.

On both systems the UNO works fine, with SerialMonitor and PuTTY, I can run some simple Serial-echo program.
On both systems the Duemilanove does not work with PuTTY, but works fine with the SerialMonitor of the IDE. There also is no problem programming.

When using the PuTTY serial connection (on either host) the Duemlianove freezes. None of the LEDs flicker when Putty opens the serial connection. The reset button doesnt do anything either. I do not think it is my PuTTY settings, as I have used PuTTY a long time (occasionally) and had no trouble previously. (I have a video proving it), Unfortunatly I can not with certainty say when it last worked (as in - "what did you do when it stopped working")

Note: with the SerialMonitor everything works as expected (LEDs briefly flash, programs starts, resetbutton works)

The natural thing is to assume that the Duemilanove is damaged (?) but what/where/how? Some small speck of ironfiling stuck somewhere? And what does the PuTTY serial do that is soooo different to the SerialMonitor that it totally freezes (or loops or whatever)?

3dprinter

#1
Apr 06, 2012, 09:27 pm Last Edit: Apr 06, 2012, 10:46 pm by Msquare Reason: 1
Just also used my Mega which also uses the 8U2 chip. Same result testing as the UNO.

Update: Just setup the USB-FTDI cable, so I talk to the Duemilanove via the TX/RX pins and not via the USB port. Power is via external adaptor. And that works.

So something has fried something on the FTDI ... but I still dont get why it matters which software drives it? (tried all PuTTY setting with respect to DTR, CTS)

robtillaart


I've used putty.exe (version 0.60)  quite a lot but never got this kind of errors,
if you communicate with the Duemilanove over (new)softsserial do the same problems occur?
Rob Tillaart

Nederlandse sectie - http://arduino.cc/forum/index.php/board,77.0.html -
(Please do not PM for private consultancy)

3dprinter

#3
Apr 08, 2012, 08:53 pm Last Edit: Apr 08, 2012, 08:56 pm by Msquare Reason: 1
Eh? Not sure I follow your reasoning. If I use SoftSerial it will be on differnet pins and I have to use the USB/Serial adaptor cable. That is what I tried on the hardware lines (pin 0/1) and there it works fine as (unclearly?) described on earlier post. Putty & Serial monitor.

As far as switching hardware and everything my conclusion at this point is that it only fails if PuTTY is talking to that FTDI chip. And in some ways academic - the way I plug my Arduino into lots of experimental setups I am not surprised something breaks (it already is the 2nd chip on that board,  :smiley-eek-blue: I've blown the poly reset fuse 3 times, and the laptop has had a few emergency power saftey shutdowns, too  :smiley-roll: )

I have an old issue with my Mega not talking to Processing which smells of a similar problem (other programs talk fine with it, on others machine (OSversion) it works with Processing). This I am getting curious what is happening with the other control-lines ie DTR/CTS/DSR and so on.

(edit: added link to "old issue")

robtillaart

I was thinking about signal strength, are the 5V signals indeed 5V?  softserial pins might just be a slightly different voltage than the FTDI chip.
But that doesn't make sense as then all serial apps should see problems.

Do you see the same trouble with other terminal programs?
I attached br@y terminal which is just one exe no installer. You can easily select handshake and some params during communication with it. I like it better for debugging serials


Rob Tillaart

Nederlandse sectie - http://arduino.cc/forum/index.php/board,77.0.html -
(Please do not PM for private consultancy)

3dprinter

Thanks, I may try that later.

I also may try and put a scope on some FTDI legs to try and guess what is happening. But may, just maybe, someone here already knows on an interpretetion of the control signals of the pseudo-COM port.

Go Up