[linux] Killing avrdude disables autoreset

[NicoHood]

If you have an issue like #3568 where you have to kill the avrdude process it will disable autoreset.

You have to manually activate it again:
stty -F /dev/ttyACM0 hupcl

[matthijskooijman]

It seems it even happens when avrdude fails and then exits by itself,
without killing it, but not when it succesfully talks to a device:

matthijs@grubby:~$ stty -F /dev/ttyACM0 -a | grep hupcl
-parenb -parodd -cmspar cs8 hupcl -cstopb cread clocal -crtscts
matthijs@grubby:~$ avrdude -p atmega328p -c arduino -b 115200 -P /dev/ttyACM0

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e950f

avrdude: safemode: Fuses OK (E:00, H:00, L:00)

avrdude done.  Thank you.

matthijs@grubby:~$ stty -F /dev/ttyACM0 -a | grep hupcl
-parenb -parodd -cmspar cs8 hupcl -cstopb cread clocal -crtscts
matthijs@grubby:~$ avrdude -p atmega328p -c arduino -b 9600 -P /dev/ttyACM0
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x46
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x61
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x69
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x6c
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x65
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0x64
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x20
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0x74
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x6f
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x20

avrdude done.  Thank you.

matthijs@grubby:~$ stty -F /dev/ttyACM0 -a | grep hupcl
-parenb -parodd -cmspar cs8 -hupcl -cstopb cread clocal -crtscts

(This was using an Arduino Uno and the Debian avrdude 6.1)

Interestingly the avrdude source code doesn't mention HUPCL/hupcl at
all.

I wonder if this should be reported at avrdude instead?

[ffissore]

Assigning to @cmaglie as this goes a bit beyond my expertise

[NicoHood]

It makes my 32u4 hang totally on some sketches. Its pretty weird. It seems that sometimes it doesnt put the magic key in ram and just reboots. I have to admit that I use my HoodLoader2 as bootloader but this shouldnt matter. If I cannot my arduino as ACM1 it works. ACM0 is broken. somehow avrdude breaks it totally if it hangs and get a force kill.

I generated this problem with hyperion (ambilight program). I opened the serial port with this and then tried to upload. Sometimes it works, sometimes not. And over the days I got this error now. As said ACM1 has no such problem so its related to the avrdude failure. In this case, with a 32u4, the patch above does not work. You need to leave the avrdude process running to force the arduino connect under a new number or reboot. The patch above stty -F /dev/ttyACM0 hupcl just hangs, no error, but no command finish. (had another hyperion open, command fixed the problem).

Putting the arduino manually into bootloader mode and then hitting upload works though. Just the reset not. I guess the dtr state is triggered badly so the watchdog will be reverted or whatever.

[matthijskooijman]

@cmaglie, I think this is an issue we should also take up with avrdude upstream soon. I'm running into this issue pretty often lately, and seen it happen with other people as well. It wouldn't surprise me if a lot of persistent upload failures on Linux are caused by this.