Core Rebooting with Previous Firmware?

So I just flashed a new build of some code I’m working on. It runs as expected, however, after about 60 seconds the core seemingly reboots itself (flashing green, flashing cyan, breathing cyan) with the previous version of the firmware! If I manually reset it or power cycle it, it will boot up with the latest flashed firmware but still reboot into the old copy after 60 seconds. If I leave it running (after rebooting into the old firmware) it will continue to reboot into the old firmware after 60 seconds.

So essentially, it’s always rebooting itself after about 1 minute. It only boots into my new code on a power cycle or press of the reset button.

I haven’t tried re-flashing the firmware yet, as I thought one of the team members might want to capture something for debugging purposes.

Anyone else seen this issue?

I was seeing some weirdness with the Spark.sleep(n); function… after putting it to sleep it was coming back after n seconds and connecting to the cloud, but not running my code from what I could tell. I had the Serial1 monitor going and the D7 led toggling… both of which stopped after the reconnect. Could be related maybe?

Hey Guys,

Nice find on this bug! The core keeps a backup copy of your firmware after a flash of new code in case something goes seriously wrong. Its possible some flag is getting confused, or some failsafe is getting triggered on accident. Any chance of sharing a code snippet that re-creates this issue for us to study?

Thanks!
David

Yeah, I knew it keeps the previous copy of firmware on the flash, so I figured it was perhaps a flag messing up or something. I’m appending my code below; it’s just some quick and dirty code to parse HTTP headers from the body. (If I can get fstream working reliably, I’ll either port or make my own HTTPClient, but right now I need something basic for my netTime library.)

    TCPClient client;

bool datavalid = false;

void setup()
{
  Serial1.begin(19200);
  Serial1.write(12);
  Serial1.write(25);
  Serial1.write(17);
  Serial1.print("READY");
  delay(1000);

  if (client.connect("www.timeapi.org", 80)) 
  {
    Serial1.write(12);
    Serial1.print("TCPClient OK");
    delay(1000);
    Serial1.write(12);
    client.println("GET /utc/now HTTP/1.1");
    client.println("Host: www.timeapi.org");
    client.println();
  } 
  else 
  {
    Serial1.print("TCPClient NOK");
    client.stop();
  }
}

void loop()
{
    char c = client.read(); // On each loop write the next available character from TCPClient to char c.
    String header = header + c; // Append the latest character into string header.
    if (client.available() && header.endsWith("X-Xss-Protection: 1; mode=block")) { // Test the string to see if we've finished reading through the headers.
        header = ""; // If so we're just going to outright discard the headers to save RAM.
        datavalid = true; // We set bool datavalid to true to signal that we've reached the body.
    }

    if (!client.connected()) {
        client.stop();
        for(;;);
    }
    
    if (datavalid == true) {
        Serial1.print(c);
        delay(50);
    }
}

Cool, thanks for posting your code! Am I correct in thinking that client.read() should maybe be wrapped in an “if (client.available()) { … }” ? (If I’m wrong please tell me, just jumped out at me)

Yeah it should, this is just an iteration of test code. I think I’ve figured out what’s happening! The core is rebooting and not clearing out any of the variables, so bool datavalid is staying true and everything is getting written out to the screen.

1 Like

To put that in perspective, the previous iteration of the firmware I had on there was just writing each character of char c out to the LCD on Serial1 with no filtering of any kind. The second iteration of the code had the filtering (above), so when it was rebooting itself it’s appearing to me as the previous iteration of the firmware. If that makes sense?

So I guess when it’s rebooting itself, it’s not clearing out the variables or anything. When I manually hit the reset button or power cycle the Core, it’s resetting that variable.

So false alarm I guess? Sorry about that! (Normally I would have just kept on trucking, but I was at a stopping point anyway last night and I figured if it was messing up a firmware flag or something, you guys might want to know about it.)

1 Like