Appearance
Loading and updating a firmware
A MUXEN box is updated over the boat's CAN bus, from the Brain, without opening anything and without a programmer.
Which image goes in which box
Released images are named after what they are:
010010005-app_scheiber-firmware.srec a CanCan v1 Scheiber gateway
010010005-V2-app_scheiber-firmware.srec the same, for CanCan v2
010010019-MODBUS-app_frigomar-firmware.srec a CAN-SERIAL Modbus Frigomar gateway| Part | Meaning |
|---|---|
| the leading digits | the product ID — which firmware this is |
| a board tag, when present | which board the image is for (-V2, -MODBUS, -SERIAL-V2) |
app_… | the program the product ID stands for |
-firmware | the update image, loaded over the bus |
Three things must line up, and only the first two are checked for you:
- The signature. Every image is signed, and the bootloader refuses one whose signature it does not recognise — before anything is written. Which keys exist depends on the line; see below.
- The product ID. Both the box and the image carry one. They must be the same, or you are changing what the box does.
- What is wired to the box must match the firmware. Nothing checks this. A gateway will happily run another line's application and then understand nothing of what is on its bus.
Read what a box currently is before touching it — see The identifiers a box carries.
How the keys are arranged, per line
| Product line | Keys | |
|---|---|---|
| CAN-CAN | one key per board — an image never crosses between them | the two generations are signed with different keys |
| CAN-MDV | one key per board — an image never crosses between them | |
| CAN-ENOCEAN | a single key across the line | one board, one key |
| BLOC 8 v2 | a single key across the line | one board, one key |
| CAN-SERIAL | one key per board — an image never crosses between them | three boards, three keys — an image never crosses between them |
Doing the update
sh
muxen-uds -i can0 listfirmware # what the Brain has
muxen-uds -i can0 -d <address> firmware --name <image>While it runs the box is out of service: it stops doing its job, and whatever depends on it disappears from the boat's screens. Expect that, and do not do it under way. The full command reference is in the muxen-uds manual, chapter Firmware.
Settings survive a firmware update. They do not survive a factory reset.
What happens if an update fails
The box holds two firmware slots. An upload writes the spare slot, never the running one. Only when the whole image has arrived and its signature checks out does the bootloader swap the two and start what was uploaded. A cable pulled mid-upload, a Brain that reboots, a corrupt image: in every case the box is left running something complete, never nothing.
What happens after the new firmware starts differs by line, and it is the difference that matters when an update goes wrong:
| Product line | On a failed start | |
|---|---|---|
| CAN-CAN | the previous firmware comes back on the next reset | |
| CAN-MDV | the previous firmware comes back on the next reset | |
| CAN-ENOCEAN | no revert — a started image is kept | images are signed --pad --confirm, so a started image is kept |
| BLOC 8 v2 | the previous firmware comes back on the next reset | |
| CAN-SERIAL | the previous firmware comes back on the next reset |
On a line that reverts, the visible symptom of a firmware that cannot confirm itself is the system LED blinking very fast and no traffic on the bus — power-cycle the box and it comes back on the previous version. On a line that does not, a started image stays; recovering means uploading a good image over it.