I was just wondering, with dfu-util, how we needed to specify the right address for each part of the system firmware. To know that particle-cli does this for us, and via OTA, is very spiffy. No climbing grain siloes needed, real or imagined!
However, i seem to have hit an obstacle:
Running the part1, then part2 OTA updates to my Photons result in a SOS (error code is 1 red blink) after each OTA attempt. Before the SOS error shows up, the OTA update seems to be stuck in an erratic magenta blinking loop for about 20-30 seconds before bailing out.
Also, I get the same SOS error regardless whether I built the system firmware from my forked firmware, or just grabbing the pre-compiled system-part1/2-0.4.6-photon.bin from github.
Luckily for me, the Photons revert back to its previous firmware version when the update fails.
Doing it via usb / dfu-util works 100% though.
Really want this system firmware OTA to work locally, any thoughts?
Happens with every Photon that I try, running 0.4.5 / 0.4.6. Form the way the LEDs are flashing, it felt like the upgrade was restarting multiple times and never completing. I'm running particle-cli 1.8.11.
@mdma, am I doing something wrong here? @tslater, how long did your OTAs take to complete for each part?
I need to try it again, but each part was under 30 seconds and it was pretty fast. Have you updated the npm package for spark-protocol? You need to delete and install the latest version if you haven’t yet.
@tslater thanks for the suggestion. That was the issue for me.
For the sake of documentation, I did apply that update on spark-protocol by @dave when it was released, to enable Photon OTAs on the local cloud. However, I did that via npm update (without deleting the spark-protocol folder first). I thought it worked as I was able to OTA user firmware without problems then.
Apparently, running npm update in the spark-server/node_modules folder isn’t quite sufficient enough. Deleting spark-protocol and running npm install did the trick as you said. OTAs for me are now working, both system and user firmware!
And, not to sound too pedantic, but I’ve also timed the local system firmware OTAs in case anyone else is wondering about their update times:
BTW, you pedantic approach is appreciated . . . I kept trying to ram part 2 immediately behind part one. I made no distinction between blinking magenta vs. breathing magenta. After I gave the OTA flash more time to complete (per your timings), it worked perfectly.
I did notice that the OTA sometimes fails, but a retry usually fixes it. I’m associating this to my bridged wireless network (and its average signal strength), but if anyone’s having similar issues, please chime in.
I have another question for the local cloud folks: what version of node are you using? I’ve been on 0.10.40 since getting it stable, and wonder if it’s worth the hassle to move up to 0.12.7 (though the rest of my software stack will be happy about that). I’m running spark-server on a RPi2.
Someone recently posted on the spark-server github #61 regarding this same issue, and I noticed that the ursa dependency has been updated to compile for 12.x.
node v0.10.25 on the remote server (ubuntu) and v0.12.7 locally (mac). I’m about to deploy a set of photons, so probably will avoid updating for some time.