Experimental full software update of Device OS, bootloader, soft device (on Gen 3), and Tinker (or Tracker Edge) in DFU mode from a Chromebook browser. No software install or extensions required.
Can upgrade or downgrade, no need to download binaries separately. You just select a version from a popup menu.
Here’s a 28 second video of a Photon flash:
Also works on Windows, Mac, and Linux on Chrome, Edge, and Opera with caveats. Here’s a video of a Boron flash from a Mac:
Also works from an Android phone in Chrome with USB OTG, no apps or extensions required.
Here’s the page, which lists all of the many caveats:
@rickkas7 could this be updated somehow so that user firmware could be flashed instead tinker? like have a file location for the user firmware?
That’s technically feasible. That’s what’s done with the hex generator for manufacturing using JTAG/SWD.
The USB device restore tool wasn’t really intended for production use, but it’s a reasonable feature request.
it could also be really helpful if we had this available on our own website. Where if clients have issues with OTA bad cell signal etc. they could easily get it updated by going to a website of ours. This would also be really help for production as all files would be maintained in one spot so everytime a version changes we dont have to reconfigure 4 or more computers.
I added custom user firmware binary feature to Device Restore over USB:
In addition to the Tinker option, there are now two (sometimes three) new options:
- Custom User Firmware Upload
- Custom User Firmware from URL
The first has a file selector button that allows you do supply your own user firmware .bin file from your browser. This is done entirely within your browser and the binary isn’t uploaded to any servers.
The second downloads the binary from a web server. I tested it using Github Pages and it worked great.
When you use the from URL option, the URL in the browser will change to be the Custom URL restore URL. If you give that URL to someone, it will pre-populate the URL and hide the unnecessary options in the page when opened.
If your binary targets a Device OS version that there is no restore available for, then the next higher version will be used.
For connecting a device is it possible to automatically reconnect to the device that was put into DFU mode? This would save and extra step when programming when the device isn’t already in DFU.
Yes and no. The problem is that when the device switches between USB serial (CDC) and DFU mode, the USB product ID changes. This makes the browser think it’s a different USB device.
The WebUSB security model requires the user authenticate each new device, to prevent web pages from accessing other USB devices you have attached to your computer.
The first time the device is switched into DFU mode, that’s considered a new device and you need to manually authorize it. For a while afterwards, the browser remembers that you’ve authorized the device and will allow automatic reconnection.
So the second time you use it, you shouldn’t be prompted to select the DFU device, but there is no getting around it the first time for browser security reasons.
@rickkas7 Man, you are rock !!! I would like to have 50% of your knowledge and then I’ll rock
Great work Rick! This is very useful in many instances. Do you think it would be possible to open source/share in some manner how this functionality was implemented? I understand it uses WebUSB, but it is not immediately clear how dfu-util was brought client side and if this is in any way replicable in a custom application (we heavily use B-Series in production and would find that capability extremely useful in our own application).
Thank you in advance.
All of the documentation is open source in the docs Github repository.
The browser-based DFU does use Web USB for the USB part, but there’s an implementation of the DFU part here. It’s from a public sample implementation, which I modified to work with Particle devices.
The code that gets the system restore zip files and calls the web DFU code is here. That’s not nearly as portable to other applications, but it shows how to call web DFU, so it may be helpful for that.
Rick, I’m trying to test out the User Firmware URL feature, but running into an issue when hosting firmware in S3. I’ve put my firmware in a publicly readable bucket in S3 and use the direct link to the binary (https://bucket-name.s3.amazonaws.com/file-name.bin) but I get the following error
Unable to retrieve the user firmware binary URL
Any Ideas on what’s going wrong?
Access to fetch at ‘https://xxx.s3.amazonaws.com/xxx.bin’ from origin ‘https://docs.particle.io’ has been blocked by CORS policy: No ‘Access-Control-Allow-Origin’ header is present on the requested resource. If an opaque response serves your needs, set the request’s mode to ‘no-cors’ to fetch the resource with CORS disabled.
Don’t really know JS, but this seems like a security issue on the app side and not S3 (though I could be completely wrong about that).
I see the problem, but the fix was not trivial. I tried just settings the CORS policy on the request but I’m getting an empty response back, and I’m not sure why that’s happening. The old way does work if there are no restrictions on the hosting web server, but I’ll have to do some more research to figure out why it doesn’t work if there are CORS restrictions on the server.
This is fantastic! Thank you @rickkas7 . Going to send this over to a customer who is in need of updating the firmware but doesn’t have the skillset to install Particle CLI and run the command lines.