EtherCAT Bootloader for Embedded Systems

How Firmware Updates Work Over EtherCAT

EtherCAT has become one of the dominant fieldbus protocols in industrial automation, robotics, and motion control — prized for its microsecond-level determinism and the ability to process frames on the fly as they pass through each slave device. But getting new firmware onto those slave devices in the field requires a bootloader built specifically around how EtherCAT moves data, which is meaningfully different from CAN-based or serial-based bootloading. This guide explains how EtherCAT firmware updates actually work, the standard mechanism behind them, and what separates a reliable implementation from a fragile one.

What Is an EtherCAT Bootloader?

An EtherCAT bootloader is firmware running on an EtherCAT slave device that allows its application firmware to be updated over the EtherCAT network itself, without requiring a separate programming interface (JTAG, SWD, UART) or physically accessing the device. It sits below the application firmware, handles the EtherCAT State Machine transitions needed to enter a programming-capable state, and manages receiving, verifying, and flashing a new firmware image.

This matters operationally as much as technically: in a machine with dozens of EtherCAT slaves — servo drives, I/O terminals, sensors — physically reflashing each one is impractical. A network-based bootloader lets an entire machine's firmware be updated through the same EtherCAT master connection used for normal operation.

How EtherCAT Firmware Updates Work: File over EtherCAT (FoE)

The standard mechanism for firmware updates over EtherCAT is FoE — File over EtherCAT, one of the mailbox protocols defined alongside CoE (CANopen over EtherCAT), EoE (Ethernet over EtherCAT), and SoE (Servo Drive over EtherCAT). FoE is a simplified, TFTP-like file transfer protocol layered on top of the EtherCAT mailbox mechanism, and it's the mechanism almost every EtherCAT bootloader is built around.

The FoE transfer sequence follows a predictable pattern:

• Master sends a Write Request (WRQ) to the slave, specifying a filename (often used to identify firmware version or target hardware) and password field.
• Slave acknowledges and is ready to receive data.
• Master sends the firmware image in sequential Data packets, each with an increasing packet number, sized to fit the mailbox size configured for that slave (commonly a few hundred bytes per packet, meaning a firmware image of any real size is broken into many packets).
• Slave acknowledges each packet before the next is sent — this is a stop-and-wait style transfer, not a windowed/burst transfer, which keeps the mechanism simple but means total transfer time scales with both image size and per-packet round-trip latency.
• Final packet is marked (shorter than the mailbox size, or an explicit end marker depending on implementation), and the slave completes the write and can report success or an error code.

Bootstrap Mode: Getting Into the Bootloader

A slave can't accept an FoE firmware download in normal operation — it has to be placed into a state where the bootloader, not the application, owns the mailbox. EtherCAT defines a specific Bootstrap state for exactly this purpose, alongside the standard EtherCAT State Machine (ESM) states:

What a Production-Grade EtherCAT Bootloader Needs to Handle

FoE itself only defines the file transfer mechanism — a real bootloader implementation has to layer several other concerns on top of it to be field-reliable:

• Image integrity verification — CRC or cryptographic hash validation of the received image before it's trusted, so a truncated or corrupted transfer (bus glitch, master crash mid-update) doesn't get flashed as if it were valid.
• Dual-bank / fallback capability — writing the new image to a secondary flash region and only switching the boot pointer after full verification, so a failed update doesn't brick the device and leave it unreachable on the network.
• Version and hardware compatibility checks — using the FoE filename field or an embedded header in the image to confirm the firmware actually matches the target hardware variant before flashing.
• Secure boot / signed images — increasingly a requirement rather than a nice-to-have, verifying a cryptographic signature on the incoming image before it's accepted.
• Recovery from interrupted transfers — handling a master disconnect or timeout mid-transfer without leaving the slave in a state where it can neither run its old application nor accept a fresh FoE attempt.

EtherCAT (FoE) Bootloading vs. Other Fieldbus Bootloaders

The throughput advantage of EtherCAT is real but often overstated in marketing contexts — because FoE is stop-and-wait rather than windowed, the achievable transfer rate is bounded by round-trip acknowledgment latency as much as by raw link speed, especially on segments with many slaves competing for mailbox cycles during a network-wide update.

A Typical EtherCAT Firmware Update Sequence in Practice

• Technician or fleet management system initiates an update via the EtherCAT master (often through a tool implementing the ETG's standard slave information / ENI configuration workflow).
• Target slave(s) are transitioned to Bootstrap (or Pre-Operational, depending on implementation) via the ESM.
• Master issues an FoE Write Request with the firmware filename.
• Firmware image streams packet-by-packet, each acknowledged before the next is sent.
• Slave's bootloader validates the completed image (CRC/signature check).
• On success, the bootloader either flashes directly or marks the secondary bank as active and triggers a reset.
• Slave reboots into the new application firmware and transitions back through Init → Pre-Operational → Safe-Operational → Operational as the master brings it back online.

If the validation step fails, a properly implemented bootloader should reject the image, retain the previous working firmware (or fall back to it from the secondary bank), and report a clear FoE error code back to the master rather than silently bricking or entering an undefined state.

Why This Is Harder Than It Looks

Two things make EtherCAT bootloading more demanding to implement correctly than it might appear from the FoE spec alone:

• Mailbox size constraints mean firmware images are transferred as hundreds or thousands of small packets, and the bootloader has to manage flash writes, buffering, and timing within whatever resource budget the target microcontroller has — often while the rest of the EtherCAT network segment continues operating around it.
• The bootloader has to survive being interrupted at literally any packet boundary — power loss, master disconnect, a dropped frame — without leaving the device unreachable. This is where dual-bank/fallback design earns its complexity: a naive single-image-overwrite approach works fine in testing and fails in the field the first time an update gets interrupted at the wrong moment.

FAQs

Simma Software builds real-time protocol stacks and flash bootloaders across CAN, LIN, UDS, J1939, CANopen, XCP, and now EtherCAT, with dual-bank fallback, image verification, and secure boot support built in. Contact us to talk through your EtherCAT firmware update requirements.