What is the "Official", "Preffered", "Most-Robust", "Most-Effective" Method to flash firmware

Continuing the discussion from Photon keeps breathing magenta and loads nothing but the Tinker [SOLVED]:

I have to say, it gets frustrating with all of the methods to get firmware updates and your code up to a Particle Device… Particle Build, Particle Dev, CLI… Trying to commit all of this to memory, or scour the forum for a possible method to attack one’s issue, well it really takes away from the awesome.

It occurs to me that Strategically-Speaking, The Particle Team should focus on a single go-to-when-all-else-fails method to get your device updated, flashed and working. Right, you have to deal with all of the personal preferences of the developers you sell, but man, there has to be a concise tool to get a listing ship righted if you are struggling.

If that already exists, it isn’t clear to me and I need to be educated on that (maybe I missed a post :wink: . Has the Particle team thought about focusing on making one of the many options as robust as possible before thinning out resources on providing other options?

2 Likes

The most robust way to get firmware on the device is by using a programmer. That should have access to pretty much everything, bootloader included.
Now, since that’s not something everyone wants to mess around with (and probably shouldn’t unless (s)he knows what (s)he’s doing), there’s the CLI. The CLI uses DFU-util to allow you to flash firmware to the device. Seeing as this is over a USB connection, this is more stable than OTA, and also faster.
Then there’s the OTA upload stuff going on in the Web IDE/Particle Dev. This is the easiest way to update/upload firmware, since you only have to click a button, without setting your device into whatever mode. No physical connection required as long as it’s online. That said, this is also the least stable option. Even though there are certain protections built-in, there’s always a risk of something going awry when WiFi decides to crap out (for whatever reason). According to Murphy’s Law, that always happens at the most inconvenient times.
Particle Dev uses the same OTA system, so it doesn’t differ much from the web IDE. Currently though, it won’t issue an OTA update even though your device might need that. If I’m not mistaken (and I very well could be), the Web IDE is currently the only one triggering that update automatically. ( <- someone please correct me if I’m wrong!).

If, for whatever reason, an OTA update failes, which can’t be solved by placing your device into Safe mode, your best bet it to use the CLI in DFU mode. First update the firmware with particle update, after which you should be able to flash your own user code. After the update, it should, once again, be able to connect and be updated OTA, should you want to do so.

If all what fails, and the Silicon Gods hate you for whatever reason, there’s still the option of using a programmer to get it completely reset. Luckily that’s rarely needed. I’ll have to refer to some of the brighter minds on here to tell you more about that, should you want to know.

Hopefully that cleared something up. (To the brighter guys on here, I know you’re reading this, please correct me if any of the above is wrong!)

2 Likes

hi @BulldogLowell! You’re right about there being a lot of resources, and we need to document this better.

The way that I see it, there are different tools for different levels. When I started out with Particle, I used a lot of the Build IDE because it was there and easy to use. As I needed to do more testing, I folded in Dev and the CLI for the nitty gritty.

I generally recommend that people start with Build, since it’s accessible and you don’t need to download anything. For code that you flash (user firmware), I think it’s important to have a lot of different ways you can do it. For code that we need to get to you (system firmware), I agree that we should have a more consolidated way to do this, and that’s currently under discussion at Particle.

In the meantime, how would you feel about a pinned post or static blog post that discusses how to do system firmware updates?

1 Like

Jordy,

I appreciate your comments, you do a good job arguing my point while you bring up yet another way of a more robust approach (i.e. a programmer) and point out that none of the available methods today (on their own) may be capable of solving most issues with a high degree of probability. As a side note, my feeling regarding a programmer is that most folks (like me) that “graduated” from Arduino to Particle would not have that tool in their arsenal.

My point is that there should be an official fallback that the Particle team supports that has the highest level of probability in solving issues related to firmware functionality and user program support because the strategy of the Particle team set out to create just that.

This rings particularly true as we experience the early release of a product like Photon. I hesitate to call it “half-baked” but let’s be honest, even now it is still a bit “doughy in the middle” with respect to its development. We are expected to make frequent firmware upgrades, if we are active in development. We see efforts to introduce richer functionality whilst we still struggle with yesterday’s promises.

Don’t get me wrong, no one is a bigger fan of this effort than me (except you Jordy, perhaps). I’m just inclined to express my thoughts at this particular (bad pun) point in time, in observance of the firmware updates that they come not as the tide, but more like single waves to the shore.

As I type this I see your note @christine… Personally, I think a single "When everything seems to have failed… do these several Particular steps in this Particular order and you should expect that your photon returns to this Particular state, ready to receive your Particular program (see how I did that!).

:blush:

3 Likes

Hopefully OTA will become bulletproof soon, having to resort to safemode or even USB wont work for deployed products, the customer may not have access to the buttons, or care whats driving their product.

And having to contact each customer to perform updates are not really going to work.

Im sure theres a lof of good people working on the software, but broken promises gets very annoying, too often is “soon”, “very soon” etc used as estimates, and often nothing have changed 2 months later.

On the other hand sometimes specific times are used and not held, so even when getting a specific date from the particle team, one cant expect it to hold up nor be notified that it will be pushed.
See the sprintf issue for example, at first it was promised in 0.4.4, then it slipped out and a specific date was set for it to return, that didnt hold up, that bug has been around since May and still alive…
“The fix is in develop now, and will be rolled out with 0.4.5 Wednesday next week (2 Sept.)” (emphasis added).

It does not fill one with confidence to build an actual product on the photon.