Activity › Forums › Questions & Troubleshooting › Software & Firmware › avrdude: stk500_recv(): programmer is not responding
-
avrdude: stk500_recv(): programmer is not responding
-
Hello, One of my controllinos mini that I bought a month ago sends me the error message:
avrdude: stk500_recv(): programmer is not responding
I have, however, loaded the same program as in my other controllino mini , and I still manage to reprogram my other controllino mini with the Arduino IDE.
After spending a lot of time on the online Arduino forums that didn’t solve my problem, I’d wanted to know what you were advising me.
Best regards.
-
I might have an similar issue, with Controllino Mini. Please help me asap, as it is used in industrial machine. So uploading worked fine, until it suddenly stopped working, with the same error. The controller itself is still running, I can access it through serial monitor through USB cable and send commands – controller is working fine. Just cant upload new program. Tried many different usb ports, com ports, baud rates etc. The same program runs fine on regular arduino uno.
So it hangs after the line
Description : Arduino
and then gives wrong data after
Hardware Version:
LOG:
Quote:
avrdude: Version 6.3-20171130Copyright (c) 2000-2005 Brian Dean,
http://www.bdmicro.com/ Copyright (c) 2007-2014 Joerg Wunsch
System wide configuration file is “C:Users…hardwaretoolsavr/etc/avrdude.conf”
Using Port : COM4
Using Programmer : arduino
Overriding Baud Rate : 115200
AVR Part : ATmega328P
Chip Erase delay : 9000 us
PAGEL : PD7
BS2 : PC2
RESET disposition : dedicated
RETRY pulse : SCK
serial program mode : yes
parallel program mode : yes
Timeout : 200
StabDelay : 100
CmdexeDelay : 25
SyncLoops : 32
ByteDelay : 0
PollIndex : 3
PollValue : 0x53
Memory Detail :
Block Poll Page Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
—-
—-
—-
eeprom 65 20 4 0 no 1024 4 0 3600 3600 0xff 0xff
flash 65 6 128 0 yes 32768 128 256 4500 4500 0xff 0xff
lfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
hfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
efuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
lock 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
calibration 0 0 0 0 no 1 0 0 0 0 0x00 0x00
signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00
Programmer Type : Arduino
Description : Arduino
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getparm(): (a) protocol error, expect=0x14, resp=0x00
avrdude: stk500_getparm(): (a) protocol error, expect=0x14, resp=0x00
avrdude: stk500_getparm(): (a) protocol error, expect=0x14, resp=0x00
Hardware Version: 4744608
Firmware Version: 0.4611299
avrdude: stk500_getparm(): (a) protocol error, expect=0x14, resp=0x00
avrdude: stk500_getparm(): (a) protocol error, expect=0x14, resp=0x00
avrdude: stk500_getparm(): (a) protocol error, expect=0x14, resp=0x00
avrdude: stk500_getparm(): (a) protocol error, expect=0x14, resp=0x00
avrdude: stk500_getparm(): (a) protocol error, expect=0x14, resp=0x00
Vtarget : 420030.5 V
Varef : 197193068.8 V
Oscillator : 0.531 Hz
SCK period : 17599574.7 us
avrdude: stk500_getparm(): (a) protocol error, expect=0x14, resp=0x00
avrdude: stk500_getparm(): (a) protocol error, expect=0x14, resp=0x00
avrdude: stk500_initialize(): (a) protocol error, expect=0x14, resp=0x00
avrdude: initialization failed, rc=-1
Double check connections and try again, or use -F to override
this check.
the selected serial port
does not exist or your board is not connected
avrdude: stk500_disable(): protocol error, expect=0x14, resp=0x00
avrdude done. Thank you.
-
Got it working now, here is the tutorial how to reset it: https://arduino.stackexchange.com/questions/22591/did-i-brick-my-controllino But I think there is some issue with this product ,I did not touch the RTC stuff. Also found another instance of this issue on internet.
Code:
I just received an answer from the official team which should work, I’ll leave it here for further reference:Open the device and disconnect (remove) connection board for approx. 30 seconds from the control board – RTC is disconnected from power (gold cap disconnected) and because of that there is reset of all RTC registers.
Plug the connection board back in to the control board. Now we need to rewrite the SW inside the Controllino which caused wrong RTC setting.
Open the Controllino example RTC sketch in Arduino IDE and prepare it to upload (function Controllino_RTC_init(0); shall reset all registers inside the RTC).
Pres and hold reset button on the Controllino device.
Connect the USB Cable (still hold the reset button, SW inside the Controllino doesn’t start)
Click for upload the sketch in Aruduino IDE and wait for „uploading“ message on debug line, than immediately release the reset button and uploading shall be finished (=> hold the reset button during the compiling phase)
If not successful, repeat the procedure
-
Hello, the issue with interconnection of the RTC INT and RESET of the CONTROLLINO MINI was solved by a hardware modification in 2016.
I assume that this is not the root cause of your troubles.
j.dacosta@cfvi.ch stated that it is still possible to communicate with the sketch – so the device is obviously not in the permanent reset state.We have observed similar behaviour too, but up to now it is not clear what is the reason. The most probable explanation is, that once you program a corrupted sketch (corruption happens during the upload) the device is then skipping the bootloader and always jumps directly to the sketch after a reset. Then the avrdude is not talking with the bootloader, but with the sketch.
Please see our FAQ No.10 here
https://github.com/CONTROLLINO-PLC/CONTROLLINO_Library#faq -
Lukas wrote:
Hello,the issue with interconnection of the RTC INT and RESET of the CONTROLLINO MINI was solved by a hardware modification in 2016.
I assume that this is not the root cause of your troubles.
j.dacosta@cfvi.ch stated that it is still possible to communicate with the sketch – so the device is obviously not in the permanent reset state.We have observed similar behaviour too, but up to now it is not clear what is the reason. The most probable explanation is, that once you program a corrupted sketch (corruption happens during the upload) the device is then skipping the bootloader and always jumps directly to the sketch after a reset. Then the avrdude is not talking with the bootloader, but with the sketch.
Please see our FAQ No.10 here
https://github.com/CONTROLLINO-PLC/CONTROLLINO_Library#faq
Thank you for the answer. Too bad I did not read this faq carefully when we had the problem. Already ordered new controller and the machine was not working for few days.
-
Quote:
Solution: The problem is not related to CONTROLLINO platform only. It seems to be a general weakness of Arduino IDE, avrdude and original bootloader. It is still not clear what exactly happens, but it seems that after upload of a corrupted binary the microcontroller skips the bootloader when reset during operation.
Are you sure it is not only Controllino issue, I have never had it with other Arduino-s…It happened again. This is ridiculous, we often need to change the code remotely, as the machine is far away – I cannot reset it remotely. I guess I cannot use this product for industrial machines as we hoped.
-
Hello, I am sorry for the situation. We will try to help you, of course!
We have spend a lot of time to investigate this issue in the past and really found some web forum posts describing the same/similar issue with Arduino.
What do you mean by “change the code” remotelly, please? Do you have your own bootloader?
Thanks!
Lukas
-
By change the code remotely I mean just changing it via Teamview-er and uploading it. We are using default settings and setup as described in manual. Maybe there are some settings that work better? See the picture:
https://www.dropbox.com/s/13hn73zb11quhn2/settings.PNG?dl=0 ” class=”bbcode_url”> https://www.dropbox.com/s/13hn73zb11quhn2/settings.PNG?dl=0 -
I understand your setup and the problem. I am afraid that existing Arduino solution (also used in CONTROLLINO) – Arduino bootloader and Avrdude commanded from Arduino IDE – is not prepared for such a usage. Please note that programming COM port open/close resets the main microcontroller. So, when you upload a sketch and Avrdude checks the content and sees that the upload has failed it closes the COM port and resets the micrcontroller = executes the corrupted binary. It may result to any issue one can imagine. From my point of view the firmware update of CONTROLLINO connected to a machine should be done very carefully, when all peripherals are disconnected or at least “deactivated” and the new FW should be verified before the machine is started again.
So, the best solution for the remote update should be to implement your own bootloader which ensures 100% secure procedure for the FW update.
What do you think?
-
I expect this isn’t the main driver of your inconveniences. We have watched comparative conduct as well, yet up to now, it isn’t clear what is the reason. The most likely clarification is, that once you program an adulterated sketch (debasement occurs amid the transfer) the gadget is then avoiding the bootloader and dependably bounces straightforwardly to the sketch after a reset. At that point, the avrdude isn’t conversing with the bootloader, however with the sketch.
-
the issue with the interconnection of the RTC INT and RESET of the CONTROLLING Smaller than usual was tackled by an equipment change in 2016. I accept this isn’t the underlying driver of your inconveniences.
j.dacosta@cfvi.ch expressed that it is as yet conceivable to speak with the sketch – so the gadget is clearly not in the changeless reset state.We have watched comparable conduct as well, yet up to now, it isn’t clear what is the reason. The most plausible clarification is, that once you program an undermined sketch (debasement occurs amid the transfer) the gadget is then avoiding the bootloader and dependably hops straightforwardly to the sketch after a reset. At that point, the avrdude isn’t conversing with the bootloader, however with the sketch.
-
Hello, I’m facing a similar problem.
We use the Controllino MEGA for our research project. We have one in our system, and I just bought a new one for developing.
After installing Arduino IDE and installing & configuring Controllino specific board and library (following manual and online tutorial), I get the message when uploading a sketch:
“avrdude: stk500v2_ReceiveMessage(): timeout” (x6)
followed by
“avrdude: stk500v2_getsync(): timeout communicating with programmer
An error occurred while uploading the sketch”.
Compared to FAQ No. 10: It never worked on this MEGA.
This happens on two systems: Windows 10 laptop (installed with admin, but run without admin) and the same on another Windows 7 Pro laptop (with full admin rights). Same issue…
Com port works: serial link established and I can get Board info.
I tried FAQ No.10, without success, and couldn’t find a solution on the internet, despite the frequent occurrence of the same or similar problems.
I hope you can help me asap as we are on a very tight schedule. (Problem didn’t occur 7 months ago on the other MEGA which is built in our system)
Thank you for your support!
-
Hello, it seems that the main microcontroller is in a permanent reset, or the bootloader is missing. At first – please check that the reset button is not stuck under the housing. -
Hi….this sort of error could be caused by your antivirus software. Try TEMPORARILY disabling your antivirus for a single compilation to see if the problem goes away, then turn the antivirus back on. If the problem doesn’t occur with the antivirus off you will need to adjust the settings of your antivirus to whitelist the appropriate file, folder, or process so it doesn’t interfere with compilation. -
Log in to reply.