Go Down

Topic: bug with serial port? (Read 6432 times) previous topic - next topic


I think you may have gotten a Diecimila that was accidently burned with the wrong bootloader (the NG one).  The Dieicmila resets when you open a serial connection to it, however, the new bootloader quickly times out and starts your sketch, even with no delay in Processing.  I should probably add in code to include the delay, but commented out, so that other people with these boards with the wrong bootloader can uncomment those lines to get the example to work.  You might also want to burn the correct bootloader onto your board.  For example, uC Hobby has instructions for doing so with a parallel programmer: http://www.uchobby.com/index.php/2007/09/12/how-to-update-the-arduino/, or you can use an AVRISP mkII and the burn bootloader command in the Arduino environment.


Hi, I am not sure how to burn an up to date bootloader with the environment. Where would I find the latest bootloader and instructions on how to do that? is there any way to check to see if I do indeed have the NG bootloader by accident?

thanks for your help! I love the arduino and the way that you can simply interface to it.


I just realized that the solution you suggested would involve me getting a parallel or other programmer for the chip. Unfortunately i can't afford that. Could I return the board and have your distributor (MAKE magazine store) replace it with one with the correct bootloader?


There is a difference in the Diecimila, in that opening a serial connection to the board will reset it.

When doing a "tail -f /dev/ttyUSB0" the first time after connecting the diecimila to the computer, it will reset and its program will run from the start; breaking out of tail (ctrl-c) and restarting it will not do that (inbetween readings are lost though). I am just too lazy right now to check what happens when the computer is rebooted while the diecimila grafts.

PS: stty reports that HUPCL is set to off on the port. Trying above procedure with the arduino-IDE serial monitor will perform the reset all of the time.


Interesting.  hungerbug, are you on a Mac?  Did you unset HUPCL explicitly with stty?  Does the board rest if you connect to it with Processing?  I'd love to find a good way for people to prevent the board from resetting every time the port is opened.


hello mellis,

this is with a recent linux system:
- no I did not set -hupcl explicitly, that seems to be the way the device gets created by udev
- when reading the serial port with a processing sketch, the arduino resets every time.
 also, if I set
  • hupcl with stty, running the sketch will again set it to -hupcl!

    what was it, you did to rxtx to make the autobootloader work on the 10k?


Actually, the FTDI drivers on both Mac and Linux automatically set (bring low) the DTR line when you open the serial port, which resets the board.  Since we've got DTR connected to reset by a capacitor, you only get the reset when the lines drops (not when it's being held low), so if you unset HUPCL (leaving the line low when you close the port), the board won't reset the next time you open the port.  On Windows you can open the port without setting DTR, but I'm not sure which programs do so.


Thank you mellis; What I think I understand, please correct me if Im wrong:
- HUPCL=hangup on close?
- When I interrupt tail-ing of the port, it will not be shut down properly, so subsequent opens will not change DTR, voilĂ  no reset.
- This is consistent with the following: After killing tail, reading the port by a processing sketch also will not reset the arduino. (above I said, it always does, but I just did shorten the story.)
- also consistent: doing a tail after the processing sketch will again reset the board.
- also consistent: if I "kill" the processing sketch, not "esc" out of it, it behaves the same as tail or "ttylog".

actually the linux kernel ftdi driver should not mess with DTR on close, if not instructed to do so: http://www.gelato.unsw.edu.au/lxr/source/drivers/usb/serial/ftdi_sio.c#L1333

PS: my interest in this discussion: it was nice to be able to connect a computer to an arduino diecimila *from time to time only* to monitor, what its doing.


Yes, HUPCL is hang-up on close.  Thanks for the information.  I'd like to find a way do something similar on other OS's, although some superficial tests made it seem like it's not as easy to prevent the board from resetting on the Mac.  I could be wrong, though.


I'm having a lot of trouble with this issue using my Mac to send data to my Arduino Diecimila.  hupcl seems to be set on the port no matter how many times I try to unset it with stty and my board always resets (taking about 11 seconds) whenever I open a connection to the serial port (using echo or screen or telnetting to serproxy).

This makes it apparently impossible to create a stand-alone command that will send data to the Arduino.  Is there anything I can do?  Is the only solution to write a program that will open the port, keep it open and then accept data from other programs?


I am able to change the value of hupcl while the port is open.  So if I open the port by telnetting to serproxy and then in a separate terminal window set -hupcl then as long as I don't close the telnet session, I'm able to echo data to the serial port and it won't reset the board.  Closing the telnet connection closes the port from serproxy and hupcl is set again and all future connections to the serial port reset the board.

It's good to know that this works, but it certainly doesn't seem like an ideal solution.


There are a couple of possibilities.  One is to set (unset?) HUPCL from within the program that sends the single command to the board - after you've opened the port.  If you do this each time, opening the port will never reset the board.  Another is, as you said, create a single program that proxies the actual communication with the board (you could use serproxy for this).

Also, if the delay is 11 seconds, it sounds like your board has the wrong bootloader.  Some of the Diecimila boards were unfortunately shipped with the NG bootloader.  If you burn the Diecimila bootloader, you'll only need a delay of a second or two, which might be short enough to just build into the individual commands (depending on what you're trying to do).


Maybe I can workaround this reset problem by using the digital pins 0,1? The setup is as follows: an arduino board that runs standalone on an external power supply. With each iteration the code dumps some values on the serial port, so a monitoring computer can be attached - this should not interrupt the running program in any way, though, so I rather not mess with DTR, which is a pain on the USB connection.

I imagine, the arduino digital pins 0,1/RX,TX map to pins 3,2 of a 9pin computer port. How do I connect computer pin 5/ground on the arduino?



I did now wire arduino TX pin1 to db9 RX pin2 and arduino GND to db9 GND pin5. on the computer nothing received on the serial port. the arduino tx led does not flash neither. computer and arduino use the same datarate. the arduino has its own power adaptor.

What am I doing wrong?


You need to do some voltage conversion between the Arduino RX and TX pins and a regular serial cable / RS232 / DB9 connection.  You might want to start a new thread about it.

Go Up

Please enter a valid email to subscribe

Confirm your email address

We need to confirm your email address.
To complete the subscription, please click the link in the email we just sent you.

Thank you for subscribing!

via Egeo 16
Torino, 10131