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 "C:\Program Files (x86)\Arduino\hardware\tools\avr/etc/avrdude.conf"
Using Port : COM6
Using Programmer : wiring
Overriding Baud Rate : 115200
The USB ports and the cables surely have no problem, I can upload to normally working boards with this set.
I can program the board with an UNO as programmer, and it works perfectly.
I set the board to DFU mode, and they were visible as AT90USB82, using Flip I uploaded the Arduino-usbserial-atmega16u2-Mega2560-Rev3.hex. The upload was successful, after reset the board is visible as Arduino Mega 2560 again.
Actually a Merlin 3d printer program is on the board, which sends info via the usb port on 250000 baudrate on serial monitor.
... but I still can't upload anything with the usb port. Why?
It's quite often something the setup tools tab.
Ports can sometimes get in a tangle even if they show OK.
Have you tried connecting and reconnecting and getting the familiar Windows com port connection jingle?
Also try restarting the computer.
And avoid USB hubs until proven OK
Do you mean you used the Uno as an "Arduino as ISP" programmer to do an Upload Using Programmer? If so, when you did that you erased the bootloader. This error is normal and expected when attempting to upload to a board without a bootloader. You need to connect the Uno back up as an "Arduino as ISP" and do a Tools > Burn Bootloader to restore the bootloader. After that, you will be able to upload to the Mega normally via the USB cable once more.
Do you have anything connected to the Mega (e.g., shields, wiring, modules, a 3D printer)? If so, try disconnecting everything from the board and then uploading to just the board by itself.
OK, so the next thing I would suggest is the loopback test. This will check the functionality of the ATmega16U2 chip used as the USB to serial adapter on the board. The fact that you were able to flash the firmware on that chip already shows it is working fairly well, but the loopback test is easy enough to run and will provide additional verification
Here are the loopback test instructions:
Disconnect power from the board.
Remove all connections and shields from the Arduino board.
Connect a jumper wire from the RESET to the GND pin.
(This is done to hold the primary microcontroller in a reset state so it doesn't interfere with this test of the USB to serial adapter chip on the board)
Connect a jumper from the RX pin (Arduino pin 0) to the TX pin (Arduino pin 1).
Connect the Arduino board to your computer.
Select the port of your board from the Arduino IDE's Tools > Port menu.
Select Tools > Serial Monitor from the Arduino IDE's menus.
Type some text into the input field at the top of the Serial Monitor window.
Press Enter.
If the text you typed is shown in Serial Monitor's output window, the loopback test passed .
If the text was not shown, the loopback test failed .
The ATmega16U2 is receiving data from the computer
There is a failure somewhere in this pipeline:
Conversion of the received USB data to serial
Output of the signal on the ATmega16U2's TX pin
Solder joint between the pin and the pad on the Mega's PCB
Traces on the Mega's PCB
Solder joint between the plated through hole on the Mega's PCB and the RX0 pin on the header
Contact between the RX0 pin on the header and the jumper wire.
Jumper wire.
Contact between the jumper wire and the TX1 pin on the header.
Solder joint between the TX1 pin on the header and the plated through hole on the Mega's PCB.
Traces on the Mega's PCB
Solder joint between pad on the Mega's PCB and the ATmega16U2's RX pin
Read of the signal on the pin.
You know it got as far as (1) because of the RX LED blink and I believe if it had gotten any farther than (12) then you would have seen the TX LED blink.
The easy part of the pipeline to check is the jumper wire continuity. They do sometimes get internal breaks so it is worth a quick check either of the wire or swapping in another one.
I made some measurements.
I checked the schematic via Arduino Mega 2560 - EasyEDA open source hardware lab
The signal comes out on M8RXD pin with 5Vpp. On the other pole of the resistor RN7.2 it is still present, but with 0.5Vpp only. It goes further through everything you mentioned, and returns to the RN7.1, and to the MEGA16U2 with the same 0.5Vpp voltage level.
I checked the resistor network, all elements are 1kOhm as needed, but I haven't soldered it out so there might be some problem with it. Anyway, I think the problem will be this low voltage.
I have soldered a 1k resistor paralel to RN7.2. The loopback test works now perfectly.
The upload still doesn't work. I re-uploaded the bootloader, but it did not help, there is something more.
I am having the same problem with IDE 1.8.19 /15. It started giving upload errors, and finally permanently upload fails. Board is Mega2560. Board and port have been verified many times.
Three other Mega2560 boards two out of the box and one a CH340 show exactly the same problem. Avrdude fails Stk500. Sync failure or timeout failure.
Arduino IDE 2.0 has no issues and uploads sketches.
Serial communication works in IDE 1.8.19 and I can send and receive via Serial Monitor.
Same problem (programmer not responding, not in sync) trying to upload to an Uno.
Could this be a baud rate problem? This issue began when the sketch was going awry due to bugs in the code. But this is only on one Mega board. The other three Mega2560 boards never ran the code. So it can't be bootloader. Maybe Avrdude detected an issue with the board while it was running the problem code, and changed something permanently in conf, or in the Windows port setup (which driver has been re-installed).
re-installed IDE 1.8.19 and 15.
rebooted PC Windows 7,
re-installed USB drivers,
reset port to default in Device Manager, it reads 9600, 8, None, 1, None
changed USB cables (both the USB-B and the micro-USB).
Nothing connected to the board pins on any of the 4 boards.
The loopback test is successful.
C:\Users\Taler\AppData\Local\Arduino15\packages\arduino\tools\avrdude\6.3.0-arduino17/bin/avrdude -CC:\Users\Taler\AppData\Local\Arduino15\packages\arduino\tools\avrdude\6.3.0-arduino17/etc/avrdude.conf -v -V -patmega1280 -carduino -PCOM22 -b57600 -D -Uflash:w:C:\Users\Taler\AppData\Local\Temp\arduino_build_371376/Blink.ino.hex:i avrdude: Version 6.3-20190619
System wide configuration file is "C:\Users\Taler\AppData\Local\Arduino15\packages\arduino\tools\avrdude\6.3.0-arduino17/etc/avrdude.conf"
Using Port : COM20
Using Programmer : arduino
Overriding Baud Rate : 57600
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x0c
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x8c
...
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x6
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x73
avrdude done. Thank you
An error occurred while uploading the sketch
Hi @protovtol. Select Tools > Processor > ATmega2560 (Mega 2560) from the Arduino IDE menus and then try uploading to your Mega boards again.
There have been two variants of the Mega board, each with a different microcontroller. The Tools > Processor menu allows you to select between the two, so it is essential to have the right setting there in order for the upload to succeed. I can see that you had "ATmega1280" selected from the menu, but you must have the other variant of the board with the ATmega2560 microcontroller.
OMG it worked! And I scoured the whole globe for a solution! I had noticed the"Processor" menu choice in the past, but couldn't figure out why would anyone select the 1280, so that it must default to 2560 processor. But no, it sticks to 1280 when changing boards, and when the board is changed back to 2560, processor remains 1280.
I did not consciously set it to 1280. Must have accidentally changed processors, without realizing it was set to 1280. I even noticed this in the avrdude command string (-patmega1280) and changed it to -patmega2560. But it did not connect for some reason. I had no idea this was a user menu choice.
Thank you so much in0. That saved me a lot of grief. I was forced to IDE 2.0 because of this, and guess what, I like it more.
.
.