Lucky me! I'm working on a fairly large project (9 peripherals) and my megas have started succcumbing to this bug. I'm an experienced programmer, and a bit manic about incremental backups, so I usually test frequently and zip my source every time I get something else working.
Last night it started. avrdude: stk500v2_ReceiveMessage(): timeout after adding some code. I noticed that after the failed upload, the mega was double-flashing at me. I suspect that means "corrupt program, upload it again". Trying the upload again, I notice the process looks normal for the first 1/2 of the time, the usual blinks, followed by the steady fast flashing of the upload. But then led13 just STOPS flashing. And a few sec later I get that error.
Unfortunately, when I try to upload again.. upload ANYTHING, it fails in the same manner. Looks to work for the first 1/2 of the time, then fails. On any short sketch I pull up, it doesn't matter.
I have to pull the USB cable from the mega for a sec to power cycle it. Plugging it back in again, it's back to doubletapping LED13, but I can upload to it again. Any other sketch is fine. But then I try to upload my big project again, and it's back to doubletapping LED13.
One of the sketches I was testing with at this point dumps a ton of hardware information as well as a bit of EEPROM, and I noticed this at the start of this mega's EEPROM. I don't know if it put it there when it got stuck, or if I just never wrote anything to EEPROM on this mega before. (I have quite a few here) Usually EEPROMs come from the factory as all FF's.
Flash Dump $100 bytes from $0 to $FF
$0000: 41 72 64 75 69 6E 6F 20 65 78 70 6C 6F 72 65 72 20 73 74 6B 35 30 30 56 32 20 62 79 20 4D 4C 53 Arduino explorer stk500V2 by MLS
$0020: 00 42 6F 6F 74 6C 6F 61 64 65 72 3E 00 48 75 68 3F 00 43 6F 6D 70 69 6C 65 64 20 6F 6E 20 20 3D .Bootloader>.Huh?.Compiled on =
$0040: 20 00 43 50 55 20 54 79 70 65 20 20 20 20 20 3D 20 00 5F 5F 41 56 52 5F 41 52 43 48 5F 5F 20 3D .CPU Type = .__AVR_ARCH__ =
$0060: 20 00 41 56 52 20 4C 69 62 43 20 56 65 72 20 3D 20 00 47 43 43 20 56 65 72 73 69 6F 6E 20 20 3D .AVR LibC Ver = .GCC Version =
$0080: 20 00 43 50 55 20 73 69 67 6E 61 74 75 72 65 3D 20 00 4C 6F 77 20 66 75 73 65 20 20 20 20 20 3D .CPU signature= .Low fuse =
$00A0: 20 00 48 69 67 68 20 66 75 73 65 20 20 20 20 3D 20 00 45 78 74 20 66 75 73 65 20 20 20 20 20 3D .High fuse = .Ext fuse =
$00C0: 20 00 4C 6F 63 6B 20 66 75 73 65 20 20 20 20 3D 20 00 53 65 70 20 20 39 20 32 30 31 30 00 31 2E .Lock fuse = .Sep 9 2010.1.
$00E0: 36 2E 37 00 34 2E 33 2E 33 00 56 23 20 20 20 41 44 44 52 20 20 20 6F 70 20 63 6F 64 65 20 20 20 6.7.4.3.3.V# ADDR op code
A bit of googling shows people using "!!!" have been having this problem for the past several years. If the version infomation in that EEPROM is accurate, I probably should get my bootloader updated. I've never done that before. I did find several places that dance around the issue, and one or two that actually provide a bit of a walkthrough on the process. I'd like to know how long that process takes. I recall at least once in the past someone saying buring a bootloader on an arduino can take an hour or more. I have a number of them to update. I'd rather a workaround for the time being.
Anyway back to my problem. Since I had only changed a very small focused bit of code and figured something had to be wrong with it, I started trimming back. I found that changing the ORDER of a few Serial.print commands fixed it. This took me quite awhile to find, even though I had a small area to look through. Anyone that's been through the process of whittling down a sketch to find a hard lock bug knows how this goes. Slow. Having to physically unplug the arduino ever time? even MORE slow.
More googling. "Remove !!! from your serial prints!" Ok. That's nice. But I don't HAVE any of that. More googling. OK here's the HEX file. Checked it. I cannot find any occurrance of "!!!". I was hoping to be able to identify a bad HEX file before uploading it. All this plugging and unplugging of USB cables is getting hard on my gear while I troubleshoot. I'd like to know if a HEX file is bad beforehand. Earlier in the thread someone said there were different symptoms showing. I'd agree this does look like a class of problems rather than one specific bug. My lack of !!! in my code suggests I have a variation on the problem.
I assume that something else I am doing in the programming is causing "!!!" or its ilk to be generated in the sketch and causing the upload to be interrupted, or perhaps the verification step that I believe occurs after the upload. But I can't find $21 21 21 anywhere in my HEX file.
This bug is repeatable on three bare mega2560s
Does anyone have any new information on this problem? I was able to "hack" my way around the bug last night, but it's come up again today and I have a much wider front to search this time. I guess all I can do is get out the knife and start carving until I narrow down the cause, or more specifically, find a place I can make any change to the code to shift whatever it is into some other form that doesn't confuse the bootloader.
little bit of an update: the last one I got around by changing a Serial.println("") to Serial.println()
THIS time I commented out Serial.print("M"); and it uploads now. So terribly frustrating having computers using $RANDOM to figure out if they're going to work today.