At first i thought it was a bootloader problem, so i've bought this little programmer, i've installed the drivers and it is correctly recognize in Device Manager. In the IDE i've selected the COM4 port where Arduino is connected, I've plugged in the ISP in the board, and i've selected ArduinoISP in the programmer menu. I've tryed to burn the bootloader and i receive this error.
But I don't think it's a USB problem. As I told you before, last time i've used the 2560, I was (probably) using it to upload a sketch into the Arduino Mini (ATmega328).
Today i've acquired a USB2Serial Adapter, i've tryed to upload a sketch to the Mini, but i keep getting this error:
When an Arduino board is recognized by the computer as serial port, that means that the usb-serial chip is working. When uploading fails, it could be a damaged bootloader (or faulty crystal, or damaged Arduino). Maybe in 30% of such situations burning the bootloader helps.
I've completely removed the drivers of the ArduinoISP, and re-installed it. Now i'm able to upload a sketch to the Mega 2560 through the programmer. But if i try to burn the bootloader i receive this error:
So everything is going well, until the written boot code is verifyed and that is wrong.
Perhaps the ATmega2560 chip is damaged after all. It could be a bad flash in the bootloader section. I have never heard of that before, and I think it is even unlikely.
To be sure about that, it should be tested with another Mega board.
Does he have a programmer ? Or an Arduino Uno to be used as ArduinoISP ?
Ask him if he can burn the bootloader to his Mega board.
If that works (of course it works), ask him to burn the bootloader to your Mega board.
Ok, so i've managed to get a working Arduino Mega 2560 board, and i've been succesfull at burning the bootloader into my 2560 board. Unfortunately i'm not able to upload any sketches to the board when using the USB cable. I keep getting this error.
You were able to use a programmer and burn the bootloader into your Mega board. Well done. It's sad to hear that it didn't help a lot.
When you upload a sketch with the programmer, the bootloader is removed. That sketch runs without bootloader.
You have to burn the bootloader again after that, to upload sketches in a normal way.
The communication chip is the ATmega16U2 used as usb-serial converter. That chip has firmware, which is in the Arduino folder somewhere. If that chip is not working, the computer would not see the serial port at all.
If burning the bootloader again didn't help, then you might need to buy another Arduino board.
Some burn the firmware in the ATmega16U2 chip to be sure that is okay, but as far as I can remember, I never had to do that.
I tried burning the bootloader using an Arduino compatable nano as ISP, and that made no difference, I tried re-burning the firmware to the 16U2 also using its ICSP headers. ICSP programming on both is successful, and the situation did not change after burning the firmware to the 16U2.
I've had a fair experience using Arduino compatable nanos with the CH340G, Arduino Nano everys, and also some usage of Atmega 1284 with Mightycore firmware, also used ESP8226s and the Pi pico. All the rest of these work now without issue, the CH340G runs fine with Linux and no need to install the driver as it's shipped ready with Linux distros. Interestingly after installing the new boards the 16U2 worked fine on the Nano every.
Then, I attempted this procedure from Arduino-er, Arduin Uno as ISP to burn Bootloader to Mega 2560, except for using the fabricated ISP jumper from above, instead of using individual jumper wires for connecting the boards.
Which is using the provided Arduino IDE > File > Examples > ArduinoISP > ArduinoISP, as below;
So with this latest failure, I did a google search of the above high lighted text and found this Arduino forums post;
Atmega (any chip) Device Signature issues and stk500_getsync()(resolutions) by hexskrew (guest).
I purchased it from the amazon store through 'NKC Electronics' which says they sell only real arduino boards...I ran into a bigger problem though.I tried it on windows...didnt work.Tried on ubuntu which involved erasing the boot loader then flashing the new hiduino image.(erasing boot loader worked/flashing new image didnt) Sooo i got a brick Wont show up in device manager besides (unknown device)
No drivers will install...nothing.I have no clue how to fix it,besides maybe trying to flash the original boot loader in ubuntu. The hiduino firmware basically turns it into a midi controller. No more serial to midi software or none of that stuff.Gonna see if i can even fix this thing.
root@linux1:/home/linux/Desktop# sudo dfu-programmer atmega16u2 flash '/home/linux/Desktop/Arduino-COMBINED-dfu-usbserial-atmega16u2-Mega2560-Rev3.hex' --suppress-bootloader-mem
Error reading line 1.
Just for some context, I have created a custom board based on the ATMega2560. I currently have the original Arduino Bootloader for the ATMega2560 and have no problems uploading code via the USB Port on TX0 and RX0.
What I am hoping to achieve is creating a custom Bootloader that allows me to upload my .hex binaries to flash but in a proprietary way, so that any program cannot be uploaded to it with the standard Wiring Protocol used by Arduino IDE. In addition, I will need a custom PC based program that can upload the code via the USB port.
The source of the bootloaders is publicly available, so a simple thing would be to make a minor modification, for example XOR each incoming byte with 0xEE. That would mean the bootloader wouldn't work with normal uploading programs (the IDE) but with a modified uploader.
However even simpler would be to upload your code using ICSP and not include a bootloader at all. Or, leave the bootloader there but turn off the BOOTRST fuse so that the processor ignores it.
In order to compile the bootloader, you need to use the avr-gcc compiler. Luckily, that comes with the Arduino IDE so you only need to add its folder to the system path. You do that by running a command from the Git Bash prompt that looks something like this:
If you're feeling very cocky with your bootloader compiling skills now and want to go for extra credit by upgrading to the superior Optiboot bootloader (which only requires a 1 kB boot section instead of the 8 kB boot section of the STK500V2 bootloader, freeing up 7 kB of program memory), you can find the source code here:
The same process as above applies to compiling optiboot. The only difference is that the target is named atmega2560 instead of mega2560 and you can specify the CPU frequency from the command line, rather than modifying the makefile:
Arduino hardware package for ATmega64, ATmega128, ATmega165, ATmega169, ATmega325, ATmega329, ATmega640, ATmega645, ATmega649, ATmega1280, ATmega1281, ATmega2560, ATmega2561, ATmega3250, ATmega3290...
The original bootloader was compiled a long time ago with a different compiler version. Note that the .hex file size is not the size it will occupy on the microcontroller. For that, use the avr-size tool, which is part of avr-gcc.
The AVR is not executing the bootloader for some reason. If the programmer is not resetting the micro before attempting to connect, this might be the reason. Try to reset the AVR (press and release the button) while the programmer is attempting to connect. Sometimes software that runs in a tight loop will prevent the bootloader from connecting.
Do you have one of these Arduino replicas or you don't have the boot-loader installed on the microcontroller? I don't know the solution to this! if you know please edit my post and add the instructions.
What solved my problem was to go to tools > boards > Boards Manager... and then on the top left of the opened windows select updatable in the Type section. Then select the items in the list and press update on the right.
This isn't really a fixing solution but it may help others. Unlike Nick had said for me it was due to code in my program. I have the mega ADK model. The issue was tied to a switch statement for processing and parsing the returned byte[] from the usb connection to the Android. Its very strange because it would compile perfectly every time but would fail as the OP had stated. I commented it out and it worked fine.
I had the same problem, and in my case, the solution was updating the usb-serial driver using windows update on windows 10 device's manager. There was no need to download a especific driver, I just let windows update find a suitable driver.
The other answers are not complete. The best thing to do is to burn a new bootloader into the Arduino Mega 2560 board, together with the newest Arduino IDE, and remove all old things that are on your computer.
Do you have a programmer ? You should get one.
After that you can start with a fresh new install.
Install the newest Arduino IDE from the official website:
When using a cheap clone board with the CH340G, use the drivers of the official website: _EXE.html
Use a programmer and the Arduino IDE to burn the newest bootloader into the Arduino Mega 2560. When you use the Arduino IDE to burn the bootloader, then also the fuses will be set to their proper values.
This guys says to manually hit the Mega reset pushbutton just as the green progress bar on the IDE from the compilation hits the right end. Another hint was to set the Preferences for Verbose (both compiler and bootloader), which consumes a bit more time with extra messages. Since it worked forme, this would seem to indicate a timing problem with the Reset pulse being too short (not getting recognized) on some systems using the CH340/341 USB to serial chips. The symptoms and his fix seem to say the hardware Reset pulse is too short in some cases, but there is enough of a timing window (in software) for the IDE to accept a manual reset if you get it at just the right time. I don't have a schematic or scope handy to check this for sure, but it may also be that the coupling cap to the Reset line from the CH part to the Mega2560 Reset is too small. Might try bridging/paralleling with a leaded 0.1uF cap across the SMD cap to see if it makes any difference, and solder one in if it fixes. Best Wishes
dd2b598166