Saving boards that time out/do not respond during upload

Development Tools Uploading
1

Hi-

I'm trying to understand if there is anything I can do to salvage four failing Arduinos.

I've looked at other issues and they don't seem to address my conditions, exactly. I'm using:
MacOS Monterey (12.5.1)
Arduino Mega 2560s
Arduino Unos
Arduino ISP 1.8.19

I've got four Arduinos, two Unos and two Megas that are all encountering issues with uploading. I also have a new Arduino Mega that I just purchased -- this new device works as expected.

The failing Megas and Unos are all failing in the same way.

For example, here are the error messages from attempting to burn a bootloader from my new Mega to one of my failing Megas. I'm following the guidance on the Arduino website with verbose output enabled:

Arduino: 1.8.19 (Mac OS X), Board: "Arduino Mega or Mega 2560, ATmega2560 (Mega 2560)"

/Applications/Arduino.app/Contents/Java/hardware/tools/avr/bin/avrdude -C/Applications/Arduino.app/Contents/Java/hardware/tools/avr/etc/avrdude.conf -v -patmega2560 -cstk500v1 -P/dev/cu.usbmodem14101 -b19200 -e -Ulock:w:0x3F:m -Uefuse:w:0xFD:m -Uhfuse:w:0xD8:m -Ulfuse:w:0xFF:m 

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

         System wide configuration file is "/Applications/Arduino.app/Contents/Java/hardware/tools/avr/etc/avrdude.conf"
         User configuration file is "/Users/mss/.avrduderc"
         User configuration file does not exist or is not a regular file, skipping

         Using Port                    : /dev/cu.usbmodem14101
         Using Programmer              : stk500v1
         Overriding Baud Rate          : 19200
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.

Error while burning bootloader.

Again, I get similar messages when attempting to simply upload successfully compiled programs any of the failing devices, ie this is the heart of the error messages:

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

The LEDs on the devices I'm attempting to upload to are the same as those on my new Mega when plugged in.

Any idea of how I might be able to salvage this failing Mega and, ideally, my other failing devices?

I've checked multiple forum issues about this previously and not had any success fixing this issue. If you have any ideas about how these failing devices can be salvaged, please let me know.

Thank you, in advance.

2

You are aware that the SPI pins on the Mega are not 10/11/12/13? So if you were using those, that is one possible reason why burning the bootloader fails.

If burning the bootloader keeps on failing, the main chip (2560 for Mega / 328P for Uno) is damaged beyond repair. On Unos with DIP version of the 328P it's a matter of replacing them by of-the-shelf ones (with or without bootloader); else you will have to desolder the main chip and replace it.

Problem is that after replacing the main chip and burning the bootloader, your don't know what other damage the board has so you might also end up replacing the TTL-to-USB converter chip (8U2 / 16U2 or CH340 or FTDI).

3

Thanks @sterretje, this is really helpful.

I'll try to replace the 328P on the Unos and see if that fixes the issue.

Please correct me if I'm wrong but the Megas don't seem to have some similarly replaceable chip.

Also re the Mega, yep I used the layout here when attempting to burn the bootloader to it: https://support.arduino.cc/hc/en-us/articles/4841602539164-Burn-the-bootloader-on-UNO-Mega-and-classic-Nano-using-another-Arduino#common-pins. Ie, I used 10/50/51/52 (plus 5V and Ground) for the source Mega, leading to Reset/50/51/52 on the Mega I was trying to burn the bootloader to, with the results summarised in my initial message.

Again, thank you for your comment.

4

I would spend the $13 for two USBasp programmers and 10-pin to 6-pin adapters.

5

Thanks @johnwasser. Can you explain a bit how you see that solving the issue?

6

If the problem is in the use of ArduinoISP to program the ATmeg2560, having a proven ISP device may eliminate the problem.

7

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.