Loading and updating a firmware

A BLOC 8 v2 is updated over the boat's CAN bus, from the Brain, without opening anything and without a programmer.

Which image goes in which box

A released image is named after the product it belongs to. The nine digits at the head of the name are the product ID:

010020008.srec

Whatever else the Brain's copy of the file carries in its name — a version, a label — those nine leading digits are what has to match the box. Ask the Brain what it holds rather than guessing:

muxen-uds -i can0 listfirmware

Two things must line up, and both are checked for you before anything is written:

1. The signature. Images for this board are signed with its own key. A box refuses an image signed for anything else — the upload fails and the box keeps running the firmware it had.
2. The product ID. Both the box and the image carry one. They must be the same, or you are changing what the box is.

Read what a box currently is before touching it:

muxen-uds -i can0 -d <address> readconfig --only-name ProductId \
                                          --only-name HardwareId \
                                          --only-name SoftwareVersion

<address> is the device address on the bus — see Reference for how it is formed.

Doing the update

muxen-uds -i can0 listfirmware                          # what the Brain has
muxen-uds -i can0 -d <address> firmware --name 010020008.srec

While it runs the box is out of service. Its outputs are not being commanded, the e-paper panel is not being refreshed, and the box restarts at the end. Everything the bloc feeds goes off and comes back.

That is not a detail on a power module. Do not update a BLOC 8 under way, and do not update the one feeding the navigation lights, the bilge pumps or anything else the boat depends on without arranging for it first. The full command reference lives in the muxen-uds manual, chapter Firmware.

Why a failed update cannot brick a box

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 the new firmware.

The new firmware then has to confirm itself: it marks itself good as soon as it has started properly. If it does not — because it crashes, or because it is not the right image for that hardware — the next reset brings the previous firmware back. A cable pulled mid-upload, a Brain that reboots, a bad image: in every case the box ends up either on the new firmware or on the old one, never on nothing.

The visible symptom of a firmware that cannot confirm itself is the system LED flashing very fast (about 25 times a second), no traffic on the MUXEN bus, a panel that never refreshes, and every output off. Power-cycle the box: it comes back on the previous version. Then check the image before trying again.

After the update

The box restarts on the new firmware with the settings it already had — an update does not reset anything. Check that it came back:

muxen-uds -i can0 -d <address> readconfig --only-name SoftwareVersion

Then check the panel: eight cells, the right names, the right states. The names are stored in the panel and survive the update; the bloc re-sends it the trip settings and its own identity after every restart. A panel that is still blank a minute later is a sign the link to it is not working — see Common mistakes.