Updating firmware on robot joint modules

By Tolerance Labs engineering team · Updated 18 October 2026

Joint firmware sets the control loops, the protocol and the protections. An update can fix faults or add features, but a robot with joints on mixed versions behaves inconsistently, and an interrupted update can leave a joint dead inside the robot.

How a joint takes new firmware

Most joints keep a small bootloader in a protected part of flash. The bootloader runs at power-up, checks the application, and either starts it or waits for a new image. The update tool enters the bootloader with a command over the bus, or during a short window after power-up. It then sends the image in blocks, and the bootloader writes and verifies each block.

Track the version of every joint

Record, for each joint: serial number, hardware revision, bootloader version, application version and a checksum of its configuration. Most joints report these over the bus. Read them at every start-up, compare them with a manifest that lists what each joint should run, and refuse to enable the robot on a mismatch. Write them into every log, so that a fault report leads back to the firmware that produced it.

Keep the images, with their checksums, under version control next to the manifest. If you cannot return a robot to a known set of versions, you cannot debug it. Update every joint of one type together, so that one robot never runs two versions of the same joint firmware for longer than the update itself.

Configuration that survives an update

Joints store settings apart from the program: bus ID and bit rate, encoder offsets, calibration tables, control gains, and current and position limits. Most keep them in a separate flash sector or EEPROM, so an update leaves them alone. Not all do, and a new version can change the layout and reset them to defaults.

• Read and save every parameter of every joint before you update.
• After the update, read them back and compare. Restore any that changed, unless the release notes say the change is intended.
• A bus ID reset to the default puts several joints on one ID. Update one joint at a time, or disconnect the others, until each ID is confirmed.
• If encoder offsets or calibration tables are lost, repeat the calibration; see calibrating a robot joint.

Power, interruption and rollback

An interrupted write leaves a partial image. What happens next depends on the flash layout.

• Single image with a protected bootloader. The bootloader finds the bad image and waits for a new one. The joint can be recovered over the bus, as long as the bootloader itself was not being rewritten.
• Dual bank, A and B. The new image goes into the unused bank, and is marked active only after it verifies. If it fails to start, the joint falls back to the old bank. This is the safest layout.
• Bootloader updates. Most joints have no fallback when the bootloader itself is rewritten. Do it only when the release notes require it, on a bench supply, and one joint at a time.

Update from a steady supply, not from a battery that is nearly empty, and keep the joints disabled. A joint in its bootloader makes no torque, so support the robot or engage its brakes before you start. Stop the robot’s controller, so it does not send commands into a bus full of bootloader traffic.

Worked example: updating a whole robot

Suppose a robot has 24 joints on four CAN buses, six per bus, at 1 Mbit/s classic CAN. The image is 256 KiB, or 262,144 bytes. Assume the bootloader protocol carries 6 bytes of image in each 8-byte frame, with the rest used for sequence and command bytes, and that acknowledgments and flash writes hold the rate to 2,000 frames per second, well below the bus limit of about 7,700.

• Frames per joint: 262,144 ÷ 6 ≈ 43,700.
• Transfer time: 43,700 ÷ 2,000 ≈ 22 s.
• Add erase, verify and restart, assumed 8 s: about 30 s per joint.
• One bus, six joints in turn: 6 × 30 = 180 s, or 3 minutes.
• Four buses in parallel: about 3 minutes for the robot. All 24 joints through one adapter channel in turn: 24 × 30 = 720 s, or 12 minutes.

CAN FD with 64-byte frames cuts the frame count by about ten, and flash erase and write speed then become the limit. EtherCAT FoE is limited by mailbox size and by how often the master polls the mailbox, so it runs far below 100 Mbit/s, though often faster than classic CAN. Time a real update of one joint and scale from it. If you update often, a multi-channel adapter pays for itself; see choosing a USB-to-CAN adapter.

Testing after an update

• Read back the version, configuration checksum and calibration of every joint, and compare them with the manifest.
• Check the direction and zero of each joint at a low current limit before any fast motion.
• Run each joint alone: enable it limp, add damping, then make small moves, and watch current, temperature and errors.
• Repeat a logged step response and compare it with the log from before the update. Changed gains or filters show up here; tuning robot joint control loops explains what to look for.
• Check every protocol change in the release notes, especially scaling, field ranges and default modes, against your driver code.
• Run the robot’s own test motions from a safe pose before normal use.
• Keep the previous image and its saved parameters ready, so that you can roll back the whole robot if any check fails.

What to ask suppliers

• Release notes for each version, listing changes to the protocol, scaling, defaults and protections, and known faults.
• Whether configuration and calibration survive an update, and which versions change the layout.
• Rollback support: dual-bank flash, and whether older versions can be loaded again.
• Signed images, and whether the bootloader checks a signature or only a CRC. A CRC detects corruption; only a signature shows that the image came from the maker.
• An update tool that runs on Linux from the command line, through the robot’s own bus and adapter.
• How long each firmware version and hardware revision is supported. Put these questions in your request for quote; writing an RFQ for robot actuators shows how.

Checklist

• The bootloader path known for each joint type, with the update tool tested on the robot’s bus.
• A manifest of serial numbers and versions, checked at every start-up.
• All parameters saved before each update and compared after it.
• Steady power, joints disabled, the robot supported and the controller stopped.
• Bootloader updates only when required, one joint at a time.
• Update time measured for one joint and planned for the robot.
• Post-update checks of version, calibration, direction and step response.
• Release notes, rollback support and signed images requested from the supplier.

Compare robot joint modules and motor drivers in Robot Parts, and ask about firmware tools and release notes when you request a quote.