I have two identical boards, one works perfectly fine, the other does not. The one that is giving me trouble, I can burn a bootloader on just fine with an AVR ISP mkII programmer. I can also use avrdude and it can erase the chip and program a sample hex file that I found on ladyada's avrdude tutorial which leads me to believe that my uC is fine. I however can not upload via the Arduino environment. Mind you, I am a newbie to the Arduino.
I get this error. I've turned the interwebs inside out (yes went through the troubleshooting guide and googled the hell out of it) trying to find out what is wrong, but solutions to this problem do not work for me (i.e. pressing reset just before hitting upload, pressing reset after hitting upload, etc).
avrdude: stk500_getsync(): not in sync: resp=0x00
avrdude: stk500_disable(): protocol error, expect=0x14, resp=0x51
You burn a bootloader through a AVR ISP mkII programmer onto the bad board using the Arduino IDE. You then disconnect your bad board from the programmer and connect the bad board to your computer using a USB cable. You then try to upload a Sketch and get the error you posted in the first message.
I uploaded a hex file through AVR dude using the AVR ISP mkII programmer, it uploaded the file. I am going to try one more thing using the AVR programmer on Friday when I get back into my lab. I do not remember if the program actually worked on the uC or not so I can not give you a definite answer at this time.
Ok, so using the AVR ISP mkII I am able to upload hex files without a problem (with avrdude). This leads me to believe that one or both RXD0 and TXD0 are not working properly on the atmega2560 since the loop back test worked fine.
If that is indeed the case then the only solution I can think of would be to change the bootloader so that instead of using RXD0 and TXD0 it uses any of the other RX/TX pins and I'd have to connect the faulty ones to them. Unless of course there is something else I'm missing...
I looked at the arduino mega 2560 bootloader source code and it seems possible to do that but I am not very familiar with the code or the arduino yet.
Just to confirm ... You've uploaded the same bootloader to both boards using the same technique. One board works and the other one doesn't.
While it seems unlikely I think the only thing left is a damaged serial port on the bad board.
If you're so inclined, you could build a simple Sketch that echoes whatever comes in through Serial; there are examples on the internet and here in this forum. The Sketch can be uploaded to the bad board using the same technique you used to burn the bootloader. Use a terminal program to send data to the bad board. If the same stuff comes back, there's something else wrong. If what you send doesn't come back, perform the same test on the good board. If the good board echoes and the bad board doesn't, the bad board has a bad serial port.
I have been able to narrow it down the problem. It seems as though the TX line on the uC (PE1) is bad or just isn't responding. I have modified the bootloader so that it will use TX1 and RX1 instead of TX0 and RX0. Only problem I'm having now is compiling it. I have the C source code as well as the makefile and have looked up many guides and tutorials with no luck.
And yes used same technique for both boards. I loaded code to make TX0 and RX0 blink, when TX did not blink, that's when I knew it was broken.
Thank you for your help. Without you I wouldn't have been able to pinpoint the issue.
I have adjusted the bootloader to use RX1 and TX1 for loading sketches, connected RX0 to RX1 and TX0 to TX1, and I am able to load sketches through the USB using the Arduino environment.
The problem now is that I cannot communicate through the USB using the native arduino functions. I suspect that arduino uses RX0 and TX0 by default when compiling the sketches. So I can either adjust my code to communicate through RX1 and TX1 by making my own functions, or adjust the arduino compiler to work specifically for my board....