Bug with !!! Using Mega 2560

This is an apparent bug with the Mega 2560. So far it has been found to not occur with a Duemilanove, but three different Mega 2560s have gotten it to occur.

When the code contains three or more exclamations it will prevent the sketch from being able to complete uploading. Note that there is no compile errors. However eventually there may be a timeout from avrdude.

An example set of code that causes this behavior is:

int IncrementingInteger = 1345;
int AlarmTriggerInteger = 1355;
boolean BooleanAlarmTriggered = false;

void setup() {
  Serial.begin( 9600 );

void loop() {
  delay( 5000 );
  IncrementingInteger = IncrementingInteger + 1;
  Serial.print( "Incrementing integer: " );
  Serial.println( IncrementingInteger );
  Serial.print( "Alarm trigger integer:" );
  Serial.println( AlarmTriggerInteger );
  if ( BooleanAlarmTriggered == false ) {
    if ( IncrementingInteger == AlarmTriggerInteger ) {
      BooleanAlarmTriggered = true;
      Serial.println( "Alarm has gone off!!!" );

Removing just one of the exclamation marks from the Serial.println ( "Alarm has gone off!!!" ); will allow the sketch to upload normally and it will work as expected. I was unable to find reference to this problem otherwise.

Devices used: Arduino Mega 2560 with Arduino IDE 0022 on a Windows 7 64bit. - Problem occurs. Duemilanove with Unknown IDE Version on a Windows 7 64bit. - No problem. Second Arduino Mega 2560 with Arduino IDE 0022 on OSX. - Problem occurs. Third Arduino Mega 2560 with Arduino IDE 0021 on Ubuntu 10.04 64bit - Problem occurs.

This was originally raised in thread: http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1294452951/0#0

If any further information is needed, please let me know.

just tried it on a UNO works fine uploaded ok and serial monitor is showing

Alaarm trigger integer xxx Incrementing integer xxx Alarm has gone off!!!

If repeatable by others, this has got to be one of the strangest bugs ever reported. ;D

Somehow my gut says there is something else going on, but I'm just a hardware guy, so don't take what I think to the bank. ;)


a long time ago in a far off computer room when operating systems were compiled from punch cards every night...

we had a strange bug then only went wrong on the 17th of the month as I recall

turned out that the bit pattern of the digits as it went past looked like the pattern for some sort of reset

... just wondering

mebbe the clever (ha ha) boot loader is using !!! as a delimiter I dunno ignore rambling

It has to be my original background in Software QA coming to haunt me like normal...

Case in point, I often use POV-Ray for some other work and have found 2 bugs there that were unknown because nobody used it in ways I did (debug file data getting overwritten instead of appended and failure rendering images 41000x41000 pixels). Go figure.

I saw the mention about the Google Code issues section (oops) and have now posted this there with all the information everyone has helped me get (and links to the posts). It is issue 459. http://code.google.com/p/arduino/issues/detail?id=459

You know !!! rings a bell now. I seem to recall the brand new bootloader used in the 2560 boards, called opti something, included a monitor function that activated with a !!! command, maybe. Possibly the bootloader is jumping to it's monitor function waiting for only valid monitor commands. Might be something you just have to live with for awhile and if fixed will require reburning a 'fixed' bootloader into your 2560.

As an experiment why don't you try ! ! ! (spaces) instead of !!! and see if that works. I don't own a mega2560 or I would try it.


Having spaces between the exclamation marks works just fine. I just removed the extra exclamation marks since it was just a happy debug note that I got the alarm working.

Looks like lefty was right and they are already aware of the issue:


Would you look at that! Apparently the search function on the issues site does not like "!!!" (which is how I checked if a bug already existed). It just lists all. But I did a search just now for Mega and found that existing one and mine. I will add a comment to mine indicating the prior bug. Now I REALLY feel redundant.

Yes we are aware of this bug. I wrote the bootloader that is in the mega. I have fixed the bug and the fix has been submitted. If anyone wants the lastest bootloader source and cant find it, send me a private message. I can also send you a hex file ready to program into the chip

The bug is ONLY in the 2560 bootloader (stk500v2) not in the optiboot which is the new uno.

The 2560 requires st500v2 protocol to be able to handle above 128K.

Lefty is correct, spaces will fix the problem. The bootloader watches for "!!!" (no spaces) to switch to monitor mode

For more info about the bootloader and what the "!!!" does, refer to