If the controller resets externally for some reason while writing the code, AVRdude gets stuck in an infinite loop avrdude: stk500_recv(): programmer is not responding

[Vinayakj009]

Hi,

I know this is an avrdude issue, but i have detected the same issue with the AVRdude bundled with the Arduino IDE 1.8.4 on MacOs

To replicate the same, you will need an Arduino, and a compiled hex file with relatively large size (2 to 4kb should be perfect).
Exact conditions for error

1. Use the following code to start upload to the Arduino
   ./avrdude -c arduino -p m328p -P /dev/cu.usbmodem1411 -U flash:w:<some_code>.hex
2. Keep your hand ready on the reset button of the Arduino.
3. As soon as avrdude goes into write mode press the reset button.
4. Do not release the button until avrdude starts giving the error
   avrdude: stk500_recv(): programmer is not responding
5. Leave the reset button.

The code gets stuck in the same loop and keeps printing the error message every 1 second.
I know I can fix this for myself by resetting the board again at the right time, but then again, I feel that the code should be able to handle this and at the least exit so that it does not claim system resources.

[matthijskooijman]

Does it keep printing the message? In my experience, avrdude usually retries 10 times and then fails when it encounters an error (OTOH, these retries are almost always pointless, after the first failure it usually does not recover, so if there is an option to disable them, that might be useful...)

[per1234]

Following your directions:

avrdude: Version 6.3-20171130
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2014 Joerg Wunsch

         System wide configuration file is "C:\Users\per\AppData\Local\Arduino15\packages\arduino\tools\avrdude\6.3.0-arduino14/etc/avrdude.conf"

         Using Port                    : COM9
         Using Programmer              : arduino
         Overriding Baud Rate          : 115200
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0xaf
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0xaf
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0xaf
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0xaf
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0xaf
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0xaf
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0xaf
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0xaf
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0xaf
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0xaf

avrdude done.  Thank you.

Problem uploading to board.  See http://www.arduino.cc/en/Guide/Troubleshooting#upload for suggestions.

Clearly this is not an infinite loop. Are you experiencing different behavior @Vinayakj009?

I absolutely agree with matthijskooijman that this retry is annoying and pointless. I always just end up pulling the USB plug when that happens. I've searched for a way to change this behavior a few times and it doesn't seem that AVRDUDE provides any way to configure it, other than modifying the source code. I did some searching without finding any related bug report or patch upstream.

Somewhat related (and all the issues that network off of it): #5928

Vinayakj009 also reported this at:

• If the controller resets externally for some reason while writing the code, AVRdude gets stuck in an infinite loop arie-g/avrdude-6.3#1
• If the controller resets externally for some reason while writing the code, AVRdude gets stuck in an infinite loop sigmike/avrdude#3

[Vinayakj009]

@per1234 : I apologize for the delayed response. I am new to raising issues and contributing to other repos.

Please check my instructions.

I said to wait till the avrdude code reaches write mode, as in it should start printing this

Writing | ################

That's when you press the reset button. Hitting the reset button, when code reaches this point is tricky if the code is very small ( 0 to 2kb hex file) that's why you need a 2 to 4 kb file so that you have time to hit the reset button.

[Vinayakj009]

matthijskooijman: Those retries are not pointless.
If you hit the reset button at just the right time, it resumes programming.

This goes for the same for the error that I faced.

[Vinayakj009]

I narrowed down the issue to the avr.c file at line number 504, 511, 662 and 1008.

Lines 504, 511 and 662 don't take care of the return code from pgm->cmd(pgm, cmd, res);

Also, there is no retry count or anything of the sort here, so the system goes into an infinite loop.

I was able to get the thing to come out of the infinite loop, with 3 retries, (I think it changes the method or reprogramming for each try) by checking if the return code is negative, and exiting the function with return -1.

I also added a return -1 to line number 1008, and now the code does not enter an infinite loop ever.

[per1234]

I can reproduce the problem using the version of Optiboot in Arduino AVR Boards but the problem does not occur using the latest version of Optiboot.

[Vinayakj009]

@per1234 : Help me understand what happens next.
Is this being taken up as an issue, or a result of depreciation?

Also, I think it would be useful to know the following (I don't really know if this is relevant or not).

I reached this issue because I was tinkering with uploading the code to the Arduino via a TCP connection. (The one where you use -P "net::")

My network was a bit slow, and the controller would exit the bootloader during the upload process, and I would see the issue.

I was able to replicate the same behavior by pressing the reset button, via a standard usb to ttl, but I originally stumbled into the issue because the programming speed was slow. What this potentially means is there may be more than 1 way to enter this infinite loop.

[per1234]

I'm just a volunteer who tries to help out with administration of the issue tracker.

If it's a problem with AVRDUDE then I suggest you submit a patch or bug ticket to them:
https://savannah.nongnu.org/bugs/?group=avrdude

Arduino does apply some of their own patches to AVRDUDE but it's not sure whether that would be done to fix such a rarely encountered and easy to work around bug. Even if they did, I think they would still want to see an upstream patch submitted for the change.