Go Down

Topic: avrdude stopped working after software update / reboot (Read 546 times) previous topic - next topic

donnz

I did a routine update and reboot on my Ubuntu 16.04 system. After rebooting, avrdude stopped updating my Nano clones. Was working yesterday, not today. It wasn't updating my Mega2560 either until after I upgraded avrdude to 6.3 (I had 6.2 prior), although my notes on that aren't good so may be a red herring.

The Nanos work if I select the "old bootloader". I never had to do that before.

I'm also seeing "Low memory available, stability problems may occur." on sketches that haven't produced that message before (entirely unmodified). The "Get Board Info" option shows "Unknown Board, VID 1A86, PID 7523, SN: Upload any sketch to obtain it (even after uploading a sketch).

The "Burn bootloader" option fails with a rather generic, "Error while burning bootloader."

Here's an example upload:
Code: [Select]
Sketch uses 8400 bytes (27%) of program storage space. Maximum is 30720 bytes.
Global variables use 1587 bytes (77%) of dynamic memory, leaving 461 bytes for local variables. Maximum is 2048 bytes.
Low memory available, stability problems may occur.
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x00
Problem uploading to board.  See http://www.arduino.cc/en/Guide/Troubleshooting#upload for suggestions.


Full settings (that don't work, and I'm pretty sure did prior):
  • Board: Arduino Nano
  • Processor: ATMega328P
  • Port: /dev/ttyUSB0
  • Programmer: AVRISP mkII


Anyway, TL;DR questions:
  • Why doesn't the "current" bootloader work? And why did it stop working?
  • Can I (or should I) update the bootloaders?
  • What's the story with the low memory warnings? Why hadn't I seen these before (on the same scripts)? And what "stability problems" are likely?

DrAzzy

Latest version of AVR boards supports the "new" nano bootloader (which due to a mistake doesn't offer much advantage over the old one), which is preloaded on new production official nano boards. Previous versions of the AVR board package did not support this nano (well, I guess, they did if you called it an Uno...). This is a poorly thought out, but intended, change.

Low memory warning is shown when 75% or more of ram is filled with global or static variables. It's a good heads up, but it's a blunt instrument for determining whether you will have memory problems - if you use String unwisely, you can have almost no memory used with global/static variables known at compile time and have memory problems, while if you don't use dynamic memory allocation at all and don't define big local variables, you can come much closer to 100% without any problems.

When you do "burn bootloader", do you have an ISP programmer connected to the ISP header on the nano? Frequently people new to arduino don't realize that additional hardware is required for this.
ATtiny core for 841+1634+828 and x313/x4/x5/x61/x7/x8 series Board Manager:
http://drazzy.com/package_drazzy.com_index.json
ATtiny breakouts (some assembled), mosfets and awesome prototyping board in my store http://tindie.com/stores/DrAzzy

donnz

Thanks, DrAzzy,


Latest version of AVR boards supports the "new" nano bootloader (which due to a mistake doesn't offer much advantage over the old one), which is preloaded on new production official nano boards. Previous versions of the AVR board package did not support this nano (well, I guess, they did if you called it an Uno...). This is a poorly thought out, but intended, change.
Ah. I was sure I'd seen "old bootloader" before, but maybe not. Looks like my boards package got updated on 9 April - possibly I'd not restarted the IDE since then.

"Poorly thought out" is right, given that it defaults to assuming the new bootloader, and won't talk to the old one in that mode. Whoever made that call needs to be introduced to the Principle of Least Astonishment.


Quote
Low memory warning is shown when 75% or more of ram is filled with global or static variables.
Right. I'd not noticed it before. The sketch I was working on had just had a big bump in size (adding a large array), but I didn't recall seeing it with the older script before - so the first time I saw the message was when the uploads had stopped working.


Quote
When you do "burn bootloader", do you have an ISP programmer connected to the ISP header on the nano?
Of course. I hadn't thought about that very hard - was trying to figure out what had changed and what incompatibility might have been introduced. I've used the ArduinoISP sketch to blow fuses on Digispark clones with the reset pin still enabled.

Is it worth updating the bootloader? If so, is the bootloader image present, or does it need to be downloaded?


DrAzzy

The only advantage of the new bootloader as implemented is that it allows you to use the WDT reset. Had they not botched the implementation, they could have made it also give you an extra 1.5k of flash.

New bootloader image is included, if you connect the ISP programmer correctly, you should just be able to do burn bootloader - the error you see suggests that it's failing to communicate with the ArduinoAsISP sketch running on the arduino acting as programmer.

TBH, if I was bootloading them, I'd bootload them as an Uno (and then call it an Uno when uploading to it).
ATtiny core for 841+1634+828 and x313/x4/x5/x61/x7/x8 series Board Manager:
http://drazzy.com/package_drazzy.com_index.json
ATtiny breakouts (some assembled), mosfets and awesome prototyping board in my store http://tindie.com/stores/DrAzzy

donnz

I meant that I hadn't hooked up an ISP programmer. I was just stabbing at the problem, unsure of how smart the bootloader upload/upgrade options were... I'm sure I've seen stuff about uploading bootloaders by first uploading a copy program to read a new image from the serial/USB and write it  over the bootloader. But I haven't done it.

BTW: is the low memory warning new, or was it always there and I just hadn't noticed?

sterretje

The low memory warning has always been there (at least since I started with Arduino with IDE 1.6.6 two years ago).

Which routine update did you do? An Ubuntu update or an IDE update?
If you understand an example, use it.
If you don't understand an example, don't use it.

Electronics engineer by trade, software engineer by profession. Trying to get back into electronics after 15 years absence.

E_Carver

Excuse me for beating a dead horse, but I'm new to all this so...

Anyway, I'm trying to upload and oscilloscope sketch to a brand-new Uno that has an ATMEGA328P-PU chip on the board. The bootloader is present (3 quick flashes of the LED when I press reset). The cable is new, too, so the problem isn't with the hardware.

In trying to upload the sketch, I get the following:

avrdude: Version 6.3, compiled on Jan 17 2017 at 11:00:16
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2014 Joerg Wunsch

         System wide configuration file is "/home/eric/.arduino15/packages/arduino/tools/avrdude/6.3.0-arduino9/etc/avrdude.conf"
         User configuration file is "/home/eric/.avrduderc"
         User configuration file does not exist or is not a regular file, skipping

         Using Port                    : /dev/ttyS4
         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=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x00

avrdude done.  Thank you.

I've tried all I can think of in tinkering with this, and I noticed that the compiler continues to use Arduino as Programmer even if I change that setting. Any help is appreciated...

BTW I'm having the same issue on both Windows 10 and Lubuntu Bionic Beaver, so I'm thinking there's a major flaw somewhere in the avrdude (whatever the H*ll that is)

DrAzzy

When programming an Uno (or most other AVRs) via the USB port - ie, a normal "upload", the "arduino" programmer option will be used (this is a slightly modified STK500 protocol IIRC).

The tools -> programmer menu has no effect except when doing "upload using programmer" or "burn bootloader", and refers to the external ISP programmer (a physical device) you are using.

The problem is not with avrdude, avrdude is trying to upload the same way it always does, but the board is not doing what it expects, it can't upload.

That error is *extremely* generic, particularly with 0x00 - it means the computer sees a serial port and can talk to it as a serial port, but that it isn't getting the right response from it for the board you have selected. Do you have anything connected to pins 0 or 1? You must not have anything connected to those pins when uploading, as they are used for the upload process - external devices loading those pins will block the upload process. Do you have the right board selected? Right port selected? Is the board you're uploading to damaged?
ATtiny core for 841+1634+828 and x313/x4/x5/x61/x7/x8 series Board Manager:
http://drazzy.com/package_drazzy.com_index.json
ATtiny breakouts (some assembled), mosfets and awesome prototyping board in my store http://tindie.com/stores/DrAzzy

donnz

The low memory warning has always been there (at least since I started with Arduino with IDE 1.6.6 two years ago).
Dunno why I hadn't noticed it then. Must be getting old.

Quote
Which routine update did you do? An Ubuntu update or an IDE update?
Yes.

I noticed after the reboot, following a (very minor) Ubuntu update. But the AVR compiler stuff updated on about a week earlier. I'd been working primarily with Nanos, but had also done updates to Digisparks and a Mega 2560; when I need to target different hardware, I usually launch another copy of the IDE - I'm guessing that the boards update happened when I did that, but since I didn't shut down the copy I was using to program the Nanos, the issue didn't show up until I re-launched the IDE after the reboot.

Go Up