Is it possible to load a pre-compiled bin file via web build

[GrahamS]

Hi,

Probably a dumb question for which there is an obvious solution - sorry if so…

I normally build and test code using Particle DEV, then do a final compile using CLI compile, to eliminate warnings and produce an appropriately named binary.

What I ‘would’ like to do is then load that bin file into the web build environment, mainly because its easier (for my client) to send the latest binary AND system firmware from there. Updating the OS (remotely) using CLI particle flash is not the most user-friendly interface ;-). Its also one step for the web build but takes at least 3 steps (per device) doing it manually. Updating to 0.4.9 has made that apparent

We could then maintain a set of bin files in the web ide and just upload the latest - or product-specific one along with its specific system version ???.

As I said - sorry if this is already feasible - I just haven’t found how yet - as I rarely use the web builder anyway :-O.

Thanks

BR

Graham

[ScruffR]

Nope, not that I know of, but AFAIK there is an API to upload firmware.
It’s featured in a forum question, but I can’t find it at the moment

[peekay123]

I believe that the enterprise dashboard can do all that and more.

[bko]

Hi @GrahamS

Here is the link to how to flash a pre-compiled binary over-the-air. You can use curl or any other web technology that can make HTTPS requests (Javascript, Python, etc.).

https://docs.particle.io/reference/api/#flash-a-device-with-a-pre-compiled-binary

[kennethlimcp]

Also… the CLI is able to handle that

[ScruffR]

@GrahamS

using CLI particle flash is not the most user-friendly interface

He knows

[GrahamS]

Guys,

Thanks for the feedback…

So using the web interface (as per the link) - does this also enforce the ‘system’ update as does the build ???.

That would be my only reason for using it - as I normally use CLI anyway…

How far are we away to a CLI compile auto-loading the requires system files ???. This is been ‘proposed’ for a while, but probably not yet mainstream…

Also - IF I use web build - will it also downgrade the System files if I build for an earlier version that that currently installed into a module ???. IE: say I use 0.4.9 and need to go back to 0.4.7. Would the web ide detect thata build was a retro-fit and reload the earlier system ???. Could be useful if it does, but definitely NOT a show-stopper if not - good to know either way though…

BR
Graham

[AndyW]

@bko

Here is the link to how to flash a pre-compiled binary over-the-air. You can use curl or any other web technology that can make HTTPS requests (Javascript, Python, etc.).

https://docs.particle.io/reference/api/#flash-a-device-with-a-pre-compiled-binary

Does that reference only handle monolithic binaries, or is is capable of flashing user and system parts also ?

[bko]

OK–good question! I just tested this and learned this:

• The format on the doc page did not work for me since the access token and the binary file have different content type requirements. I switched the curl -H "Authorization: Bearer 1234" and that worked. Doc issue to be filed.

• I tried to take a bin file generated on the webIDE for 0.4.9 (latest) and apply it to a Photon that was running 0.4.7, so an update should be required. This put my Photon in safe mode, indicating that the code could not be run. An automatic update was not triggered in this case for me.

• I then used this URL method to flash part1 and part2 and then my binary to my device. That works fine.

I was not able to test monolithic binaries.

[MORA]

PHP script to send same bin file to multiple devices via API.

<?
define('TOKEN', 'YourAccessTokenHere');

if (isset($_POST["flash"]))
{
    $filename = $_FILES["firmware"]["tmp_name"];

    move_uploaded_file($filename, "firmware.bin");
    $filename = "firmware.bin";

    foreach ($_POST["target"] as $device)
    {
            $data = array("file_type" => "binary", "file"=>"@".$filename);
            $ch = curl_init("https://api.particle.io/v1/devices/".$device."?access_token=".TOKEN);

            curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
            curl_setopt($ch, CURLOPT_CUSTOMREQUEST, "PUT");
            curl_setopt($ch, CURLOPT_POSTFIELDS,$data);

            $response = curl_exec($ch);
        $status[$device] = $response;
            if(!$response) {
                return false;
            }
    }
}

$res = file_get_contents('https://api.particle.io/v1/devices?access_token='.TOKEN);
$devices = json_decode($res);

echo "
<form method='post' enctype='multipart/form-data'>
<table border=1><thead><tr><th>Select</th><th>ID</th><th>Name</th><th>Last IP</th><th>Last connected</th><th>Connected</th><th>Status</th></tr></thead>";

$default = array();

foreach ($devices as $device)
{
    echo "<tr>
        <td><input type='checkbox' value='".$device->id."' name='target[]' ".(in_array($device->id, $default)?' checked ':'')."></td>
        <td>".$device->id."</td>
                <td>".$device->name."</td>
                <td>".$device->last_ip_address."</td>
                <td>".$device->last_heard."</td>
                <td>".(($device->connected==1)?'Yes':'')."</td>
        <td>".$status[$device->id]."</td>
         </tr>";
}
echo "</table><br>
<input type='file' name='firmware'><input type='submit' value='Flash now' name='flash'>
</form>";

[GrahamS]

Guys,

Many thanks for all these replies.

To cut through it all then - the answer to my original question is NO.

The Web Builder cannot be used to simply install a pre-compiled binary image.

The ‘other’ methods all suffer from their inability to inherently update the system code.

Thanks at least it is quite clear ;-)) - I hope this is a reasonable summary…

Is there a forecast date for availability to update the system files from CLI and/or Particle Dev ???.

NB Not ignoring you @peekay123 - tried the enterprise stuff some time back and it didn’t seem to be right for my needs…

Thanks again

Graham

[MORA]

I think if you load a user firmware build against a newer system firmware over the API the photon will enter safe mode, and the safe mode updater will update the system firmware.

Correct me if im wrong though

[AndyW]

Question: if I fire off 3 firmware update messages (system parts 1 & 2 and then user) will the cloud queue these (either explicitly or just the way it happens) and make it just work ?

[kennethlimcp]

If you use the the Web IDE to perform a OTA for a user firmware that requires a higher version of system firmware than the currently available on the device, the handles the system update in the following sequence:

• user firmware
• system firmware part 1
• system firmware part 2

This is handled and queued by the .

If you were to do it manually in 3 parts, the sequence matters and you have to make sure that the device is back online before OTA-ing the next one as the does not queue them up.

[AndyW]

Hmm - I was thinking of adding a target to the local build makefiles that used OTA to program the 3 parts (which would save a lot of faffing about with usb cables and DFU mode button pressing) - but it looks like that’s not possible unless there’s a way to provide timing feedback so the make can stall updating a particular file. If the cloud would queue these up, it would be trivial.

I realise the local build builds the user section last, and you’re saying that needs to be blown first by the cloud, that’s easily doable.

[mdma]

If using stock system firmware is ok, then you only need to flash the user app, and let the cloud flash the needed system firmware.

If you want to flash custom system firmware, then it’s best to flash in the order you wrote above - system part 1, 2 and then user part. At present the tricky part is the command-line OTA - it’s asynchronous. If we can make the command line OTA update synchronous then that would provide a simple solution.

[AndyW]

Yup - or even if the queuing was moved from where-ever it currently happens in the web-ide to the cloud proper, so that curl access to the endpoint also queued, that would rock. However a synchronous endpoint (with the timeout as a parameter) would also be a fine, workable solution.

The main purpose for me doing this would be changing the system parts, if it was just the user part, I think there are already myriad ways to do that.

Off topic, but of interest to me: why do the 3 parts need to be programmed in that particular order, is it to ensure that the device always finds itself in safe mode after the interim restarts ?

[mdma]

It’s because of versioning dependencies. System part 2 is dependent upon functions in system part 1 - if a newer system part 2 were flashed before system part 1 it may try to use functions that don’t exist in the previous version of system part 1. Flashing in dependency order ensures dependencies are met.

When flashing OTA, the dependencies are checked, so an out-of-order flash results in the flash being ignored rather than possibly corrupting the firmware.

Turning to the application, when the application dependencies aren’t met then the system doesn’t load the application firmware and enters safe mode, for the same reasons of dependency resolution - the application may be using new function calls that don’t exist in the previous system firmware.

System firmware is forward compatible, so it’s fine to load newer system firmware without updating the application.

[AndyW]

Thanks.