Self-Destruct

Is there a way to cause an Atmega to overwrite its own program?
Like, with nulls or something?

I've never seen a memory map, but I'd really like to put a feature in some code I'm working on that has a Self Destruct switch. If pressed, the arduino (Atmega328P) will overwrite the code in the flash, and become inert. It'd be nice if the bootloader was still there.
Any suggestions?

Is there a way to cause an Atmega to overwrite its own program?
Like, with nulls or something?

Sure. Just upload the example file in the IDE called BareMinimum.

void setup() {
  // put your setup code here, to run once:

}

void loop() {
  // put your main code here, to run repeatedly: 
  
}

This will erase any previous sketch that might have been in the chip's flash memory. The Arduino bootloader will not be erased as the fuse settings are set such that the bootloader portion of the chips flash memory is protected.

Lefty

I was actually thinking about an Atmega that was in-circuit at the time of it's own self-destruction.

I.e., not connected to an ICSP or USB. Just sitting out there, in a project box somewhere, plugged into a wall-wart or batteries, and then, under program control, it overwrites the program in flash.

under program control, it overwrites the program in flash.

Nothing comes to mind that is in anyway practical. However you could have a software function that activates the watch dog timer with the minimum disable time possible, this would in effect keep it in a loop just resetting the chip without anyway to recover from it. Most would call that a fatal software bug, but hey if it suits your requirements?

Maybe if you could explain the need for this functionality, a different solution would present it's self. There are cleaver people roaming these parts.

Perhaps you could create a customized bootloader that would do two things before transferring control to your sketch:

  1. It would find the address to a custom function (in your customized bootloader) to overwrite the area of memory set aside for the sketch binary.
  2. It would write to the EEPROM this address.

In your sketch, when it first starts, you would read this address from the EEPROM and store it in a variable (this way your sketch could use the EEPROM and overwrite that memory area if needed).

When you needed to obliterate the sketch, just transfer execution of the code to the memory location pointed to by that variable, which would execute the function in the bootloader "segment", overwriting the sketch area, but leaving the bootloader intact.

/anyway - that seems plausible... ::slight_smile:

A puzzle box (with a tricky puzzle) has the option of, if the puzlee gets too frustrated, of just saying, "Oh, to heck with it!" and pushing the "Open it Now" button, which has the side effect of erasing the chip so that it has to be removed from its socket and reprogrammed if you want to play with the box some more.

Use a flag in EEPROM. If the flag == 0xFF then the puzzle runs. If the flag != 0xFF then the puzzle does not run. If the human pushes "Open it Now" then change the flag to 0x00 and stop running.

When you upload a sketch, does it reset EEPROM data?

If not, then a second program could be uploaded that was just:

const int DontRunAnyMore = 5;

void Setup(void)
{
write(DontRunAnymore, 0);
}
void Loop(void)
{}

When you upload a sketch, does it reset EEPROM data?

No.

If the EEPROM is erased when a Sketch is uploaded, it's because the fuse settings are wrong and you should treat it is a bug with your board.

Could it be done with another board attached to it? like on triggering a digital in, the board could send serial commands to your arduino to reprogram it to whatever you want (bare minimum or ???)

If you could make that work, you could start testing a whole array of boards which could all reprogram each other on different conditions, right?