Hello,
and after that what shall I do ?
Hello,
and after that what shall I do ?
Okie doke will send again
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
@Moors7 Thanks a lot ,
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
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
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;
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.
@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.
@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.
@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.