Activity Forums Questions & Troubleshooting Software & Firmware avrdude: stk500_recv(): programmer is not responding

  • avrdude: stk500_recv(): programmer is not responding

     Lukas updated 4 years, 1 month ago 6 Members · 15 Posts
  • j-dacostacfvi-ch

    Member
    February 8, 2019 at 11:48 am

    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.

  • ingmar

    Member
    February 8, 2019 at 3:09 pm

    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-20171130

    Copyright (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.

  • ingmar

    Member
    February 11, 2019 at 4:59 pm

    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

  • Lukas

    Member
    February 12, 2019 at 9:03 am

    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

  • ingmar

    Member
    February 12, 2019 at 3:38 pm

    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.

  • ingmar

    Member
    February 20, 2019 at 2:46 pm

    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.

  • Lukas

    Member
    February 22, 2019 at 10:01 am

    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

  • ingmar

    Member
    February 22, 2019 at 4:22 pm

    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

  • Lukas

    Member
    February 26, 2019 at 4:10 pm

    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?

  • tara

    Member
    March 27, 2019 at 11:40 am

    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.

  • tara

    Member
    March 28, 2019 at 9:51 am

    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.

  • jbileuv

    Member
    June 17, 2019 at 12:27 pm

    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!

  • Lukas

    Member
    June 17, 2019 at 12:49 pm

    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.

  • billytse

    Member
    July 2, 2019 at 5:52 pm

    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.

    pcb assembly

  • Lukas

    Member
    February 28, 2020 at 3:11 pm

    I have some news regarding this topic – we have found some potential root cause of these troubles in the original Arduino bootloader.

    Please see this tutorial THIS TUTORIAL how to update to the new MINI bootloader.

    Note: This is relevant only for MINI!

Viewing 1 - 15 of 15 replies

Log in to reply.

Original Post
0 of 0 posts June 2018
Now