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.
No comments:
Post a Comment