By Maryam Khagani (CAN in Automation)
Firmware updates are an essential part of maintaining embedded systems,
especially in environments where devices are expected to run
continuously and securely over long periods. Ensuring secure firmware
updates in CAN-based systems requires a harmonised approach,
particularly when devices from multiple application domains are
involved. The draft specification proposal (DSP) CiA 710, developed by
CAN in Automation (CiA), introduces a harmonised approach for
implementing a generic CANopen bootloader, applicable to both CANopen CC
(classic) and CANopen FD devices. Its primary objective is to ensure
reliable and secure firmware updates, regardless of device manufacturer
or application domain.
Maryam Khaghani, the author of this article, earned her Bachelor's degree in Electronic Engineering in Iran in the year 2014. Later that year, she began her professional career in the R&D department of an Iranian company specialised in the production of elevator control panels and related equipment. After eight-years experience in research, development, and technical troubleshooting, she joined CAN in Automation (CiA) in 2023 as a Technical Manager. In her current role, she actively contributes to the development of CAN technology by participating in technical working groups, presenting CAN-based webinars, and supporting the creation and improvement of technical specifications related to CAN-based systems.
In a CANopen device, a bootloader is a minimal program, responsible for
initialising the hardware and managing firmware updates over the CAN
network. If an update condition is triggered (e.g., by a reset, specific
state, or command), the bootloader enters update mode and awaits further
instructions via the CAN network. CANopen bootloaders ensure that
devices can receive new firmware versions via CAN. Their presence
provides system maintainers with greater flexibility to apply updates in
the field. A new version of device firmware may remove identified
security weaknesses or may add new application-related functions. Thus,
the bootloader extends the longevity of devices.
Bootloaders are critical for supporting field updates without requiring
physical access to the device. In lab environments, they allow rapid
firmware iteration and debugging. During end-of-line production, they
enable final firmware to be flashed onto hardware just before shipment.
In deployed systems, over-the-air updates (e.g. through a gateway) or
remote maintenance become feasible through the CAN network, eliminating
the need for disassembly or direct reprogramming. This flexibility is
especially important in distributed control systems, industrial
automation, and remote or safety-critical environments.
CiA 710 aims to harmonise this functionality, ensuring consistent
bootloader behavior across devices and allowing tools to manage updates
using a predictable and well-defined interface.
Key features of the CANopen bootloader
To harmonise firmware updates over the CAN network, CiA 710 introduces a
finite state automation (FSA) model for embedded devices (see Figure 1).
This model ensures predictable device behavior across different
operational states, allowing configuration tools and host controllers to
manage devices consistently. The FSA defines two main modes, bootloader
mode (BM) and application mode (AM). When a CANopen device is powered
on, it first enters the bootloader initialising state. It then checks
for a valid application using data object 1F59h. If no valid application
is found or intended, the device defaults to bootloader mode. In this
mode, it performs setup operations such as CAN controller initialisation
and bit rate configuration, according to CiA 1301. In BM, the device
requires user authentication. Authorised tools or host controllers can
identify themselves, which allows the device to proceed to the “BM allow
application download” state. Here, it waits for a new application.
Before downloading firmware, tools can read attributes like flash status
and operation times, helping them adjust internal timeouts and behavior
accordingly.
Once the application is successfully transferred, the device is
instructed to exit BM and usually starts the new program, entering
application mode (AM). If a return to BM is needed—for reconfiguration
or complete application replacement—the tool must re-authenticate, and
the system must verify that the current application allows safe
switching back to BM. To avoid device loss during faulty firmware
transfers, CiA 710 includes a rollback function. If an error occurs, the
device will reboot with a default pre-configured application.
Overall, CiA 710 enables tools and CANopen host controllers to
orchestrate the operating states of the device, to ensure secure
firmware updates, and to maintain the integrity and reliability of the
system operation.
 |
CANopen bootloader and application FSA (Source: CAN in Automation) Bootloader operation from the client perspective
Click to expand |
From the client’s perspective, using a CANopen bootloader involves a few
structured steps to update an outdated application on a device. The
update begins with a security handshake. Since firmware-related
operations are protected to prevent unauthorised access, the client must
first request a security challenge from the device. The device responds
with a random value, and the client returns a computed key based on that
value. If the response is correct, the device grants the client
permission. Once access is granted, the client switches the device from
application mode (AM) to bootloader mode (BM) by writing specific values
and triggering a timeout. In BM, after the client sends a request to
erase the current application program, it monitors the flash status
until the confirmation of erase operation is completed. Afterward, the
client begins downloading the new application program in segments,
verifying each part is correctly written by checking flash status and
timeouts.
Once the full application is downloaded, the client switches the device
back to AM by sending a control command to start the program. Finally,
the client verifies that the new application allows returning to BM,
ensuring future updates remain possible. During transitions between AM
and BM, device identification parameters may change accordingly.
Summary and conclusion
A bootloader is a fundamental function in modern embedded control
systems, offering a flexible method to react on modified system/device
requirements, by means of a device’s firmware update over CAN. The CiA
710 specification represents a significant step forward in this field,
providing a harmonised, secure, and device-independent framework for
managing firmware updates in CANopen systems. By defining a clear finite
state automation (FSA) and incorporating authentication mechanisms,
timeout management, and rollback capabilities, it ensures that firmware
updates can be performed reliably. From the perspective of both the
device and the client tool, the update process becomes predictable,
structured, and resistant to error or unauthorised access. For
integrators and device manufacturers, adopting CiA 710 provides a clear
path to improving maintainability, security, and long-term lifecycle
support of CAN- connected embedded devices.
@CANopen #PAuto #Communcations
