Photon not flashing correctly, or always flashing with tinker

Hello,

and after that what shall I do ?

Okie doke will send again :slight_smile:

The proceed to step 3 above please to generate new keys.

I have an

Error saving key from device… Error: Command failed: unable to load Private Key

Try running particle keys new again and make not of what new files it creates. Did it create a device.pem file?

Hi @epierre

When the keys are bad on the device, then these steps won’t work since particle tries to save the existing key.

Please try the steps described here - Photon setup flashing cyan with a "quick red burst" (now orange burst) [Solved]

Hi,

My photon had exactly the same issue (wouldn’t flash from web IDE, green LED flashing) but flashing the 0.4.2 firmware fixed it for me

Mark

Hi, I am using Particle Dev and I’ve had problems with flashing firmware to my photon.

It’s kind of weird, because some times it’s seem to be flashed(include flashing magenta), but when check it the software wasn’t updated. I have no idea how to solve it, except replacing the photon to a new one(but I have limited number of photons)

Any idea why is it behave like this?

Could you try flashing a simple app (blink an LED) from the web IDE so your system firmware can upgrade. See if that helps and report back :slight_smile:

@Moors7 Thanks a lot :smiley: ,

It works, but should I flash the test app in each device before start to program it? When this firmware upgrade happened? Is there a more quick and easy way to do it? yesterday it worked perfectly :pensive:

Unfortunately there is no way (yet) to select the target firmware version in Dev or CLI.
So if you want to use CLI or Dev you’d need to upgrade to the latest firmware version before flashing new code.
But there are other ways than only Web IDE

e.g. see
https://github.com/spark/firmware/releases/

Glad to hear it worked!

You won’t have to flash the test app each time. The reason I told you to use the test app was twofold;

  1. It is known to be working, eliminating user error.
  2. It initiated an automatic update when flashed from the web IDE.
    Both are equally important, since some users get overconfident in their skills, and start to think they’re flawless. Having something that is simple and known to be working really helps then :wink:
    The automatic firmware currently only works from the web IDE (someone correct me if I’m wrong), so that will allow you to update the easiest way possible. Flashing your own app would’ve updated it as well. Actually, anything would do, but then point 1 comes in again :wink:

There are alternatives for updating system firmware, but flashing anything over the web IDE is currently the easiest way for most people. Work is being done to support this with other tools in the future.

2 Likes

@Moors7 Thought I would reopen this thread rather than a new one!
I just noticed an issue this weekend where I have upgraded firmware to 0.5.2 and successfully flashed a new app. However, now when I try to flash an amended version of the same app it all appears to work (from the Web IDE) with the confirmation Flash Successful! but then does not actually update the device app. I know it is not updating because I have an App version displayed on restart and available as a cloud var. Any suggestions as to why the device is rejecting the changed app but reporting Success? Thanks

That’s usually an indication that your running code “messes” with the OTA download so that the new firmware doesn’t stick.

You can check if you get a new app-hash message in https://console.particle.io/logs
And you can try flashing while your device is in Safe Mode.

After that you could try to pin down the part of your code that messes with OTA.
SYSTEM_THREAD(ENABLED) also makes OTA flashing a bit “fuzzy” since you might need to wait a few sec after dropping out of magenta.

1 Like

@ScruffR Thanks for those pointers. I have used Safe Mode before to ‘encourage’ the OTA flash to work. It is not a ‘production’ solution. I am a bit worried about the last bit of advice. My app contains a user option to switch off OTA updates but this is not anything that has caused a problem before V0.5.2. What other things in code tend to ‘mess’ with OTA? Just so I can cross-check with changes made since last version that successfully flashed.

One more data point. I have been seeing a similar issue over the past two days.
Flashing an app built using a newer base firmware (0.51->0.52) via dfu-util does not auto update the base OTA.
I’m building using release/0.52 branch locally for the P1.
This was working fine last week.

Edit for clarification:
Unit has 0.51 base, being flashed with an app built using 0.52. Goes into safe mode after just app (user-part) is flashed and does not OTA the base-part. I need to manually flash the 0.52 base parts.

Anything that starves the background thread of processing time, like longish frequent calls to delay(), long running loops, anything that takes control of WiFi and/or cloud connection without checking the system status, …

@ScruffR The code flash issue appeared to be related to a function that I had lifted to debounce a switch that was passing back a boolean value in the function parameters. So the function was defined thus (simplified):

void debounceSwitch(bool *_switchChanged)
{
     _switchChanged = false;
     if (rawValue != debouncedValue)
     {
          .....
          _switchChanged = true;
     }
}

My understanding is that this is one way in C++ to pass back more than one value (although in this case there was only one value), the deboucedSwitch value being a global variable.

In the function call I was

boolean *signal_changed;

debounceSwitch(signal_changed);
if (&signal_changed)  .... read global variable decouncedSwitch value

My question is whilst this compiled why would it have caused the flash error?

I’m a bit confused about your code there.
The way you are using the pointer seems not right to me.

to set the value, you shoud rather write *_switchChanged = false;
and to pas your global into the function you’d write debounceSwitch(&signal_changed);
and that variable should be daclared bool signal_changed; otherwise you only create a pointer to a bool but not actually a variable to point to.
and with that you’d use that boolean just like if (signal_changed).

That code would build but the code flow will not be as you expect it since your values will be all muddled up.

1 Like

@ScruffR Sorry a bit rushed as was on a lunch break when writing this post. I see what was causing the problem - compiler didn’t complain but it when I tried to use the variable. Thanks.

1 Like