Flash .bin file to Electron - Does this overwrite all previous code?

Getting Started
1

Hi. Yes another very basic question!!
When I flash a binary to the Electron (in my case I am doing this over serial from the CLI), is the entire program memory of the Electron “wiped” and replaced with the new binary?
I ask this question because I had a previous “blink” program compiled and loaded and successfully blinking. It looked like this:

int led1 = D0; // Instead of writing D0 over and over again, we'll write led1
// You'll need to wire an LED to this one to see it blink.

int led2 = D7; // Instead of writing D7 over and over again, we'll write led2
// This one is the little blue LED on your board. On the Photon it is next to D7, and on the Core it is next to the USB jack.

void setup() {

 
  pinMode(led1, OUTPUT);
  pinMode(led2, OUTPUT);

}

void loop() {
  // To blink the LED, first we'll turn it on...
  digitalWrite(led1, LOW);
  digitalWrite(led2, HIGH);

  // We'll leave it on for 1 second...
  delay(1000);

  // Then we'll turn it off...
  digitalWrite(led1, HIGH);
  digitalWrite(led2, LOW);

  // Wait 1 second...
  delay(1000);

  // And repeat!
}

Then I coded a simple program to turn pin D6 off with no blinking in the program like this:

#define PIN D6
int state = 0;

void setup() {
    //tell the device we want to write to this pin
    pinMode(PIN, OUTPUT);
}
void loop() {
    //Turn Pin Off
    digitalWrite(PIN, LOW);
}

It successfully compiled and I flashed it, but the previous blinking D7 LED started blinking after the flash.
I had assumed my new program would overwrite the old one and the blinking LED would stop…

I suppose I am just after a bit of explanation for where I may have gone wrong either in my assumptions or programming…
Thanks.

2

Yes. The old program is completely erased when flashing. Sometimes (though I’ve never seen it over serial or DFU) the new firmware doesn’t “take” and I like to check this by using a cloud variable tied to a “version” variable I change every time I complete. For example:

char *version= "0.1.0";

void setup()
{
Particle.variable("version", version);
}

and then, to grab the current version, you can, using the Particle CLI call particle get <device name> version to retrieve the current version number to make sure your flash was successful.

3

Just to clarify:
No not the entire program memory but only the user application area.
The bootloader, system part 1 & 2 and the retained data store are untouched when flashing new application firmware.

4

If you’re dong it over serial via the CLI then make sure you have crc32 in your path, or the resulting binary may not be valid, and will be ignored by the device.

5

Thanks to @mdma @ScruffR and @harrisonhjones for your help.
I just found the problem. I had copied some commands and managed to compile for the Core! (I was flashing an Electron).
It compiled and flashed OK (at least it gave the response that it flashed successfully), but obviously I flashed a bin file for a Core to an Electron, I presume it chose to ignore it and retained the previous code I had loaded.

6

I’d guess flashing via DFU might have given you a more elaborate feedback pointing you at the incompatible platform ID.
This is one of the reasons why I still stick with particle flash --usb firmware.bin since I already have dfu-util installed :wink: