CANopen is a popular higher-layer protocol for a CAN based embedded distributed network. It provides a ready-to-use and proven blueprint for application data exchange between multiple nodes on a CAN network. Furthermore, CANopen includes network management functionality and pretty much everything else you need to get a CAN system up-and-running. Unfortunately, the CANopen protocol specification does not specify how a CANopen bootloader should behave. This article explains how you can make use of the OpenBLT bootloader in your CANopen network and rely on it for making firmware updates on your CAN nodes.
When you adopt CAN for the first time in your multi node system, it can strike you as an overwhelming task. Soon you will have questions to answer such as: Which CAN message identifiers should I pick for my application data? How should I monitor the availability of other nodes? How do I select the right bit-timing? In such a situation, it might be worth considering the application of CANopen.
If you plan on developing an off-the-shelf microcontroller based product that supports CAN communication, CANopen could be a great choice too. You customers can then easily configure and integrate your product into their own CAN network. You can market your product as a plug-and-play CAN node.
CANopen bootloader options
While architecting your CANopen system, sooner or later you probably decide that a bootloader might be nice to have. With the bootloader, you, your field engineer or end-user can perform a firmware update, whenever a new firmware version becomes available. With a bootloader in place, you can quickly and easily make critical bugfixes and new functionality available to your end-users. So off you go and research how to get your hands on one of those shiny CANopen bootloaders. Soon after, you find out that the CANopen protocol specification does not specify how a CANopen bootloader should operate. Sure, there are solutions out there that offer proprietary CANopen bootloaders. These solutions are typically based on SDO transfers to communicate the new firmware data to the target.
As an alternative, you could consider choosing the OpenBLT bootloader. It does not implement a CANopen protocol stack. Instead, it contains the XCP communication protocol for firmware data exchange. This is actually beneficial, as the XCP communication protocol has less overhead and results in a low ROM footprint of the bootloader. Consequently, your own firmware has more flash memory at its disposal.
Moreover, the OpenBLT bootloader is open source under the GPL v3. This means that you can fully evaluate its code quality and try it out for free. If you do not like it, you can always look for a different solution and it didn’t cost you a dime. In case you do like it, you could consider purchasing the commercial license from Feaser. With the commercial license you can make use of the OpenBLT bootloader in your product without having to open source your own firmware. Additionally, you support the OpenBLT project, as it enables Feaser to continue sponsoring the OpenBLT project.
Configuring OpenBLT for usage in a CANopen network
The XCP communication protocol, upon which the OpenBLT bootloader is based, only requires two CAN identifiers to work. One for sending commands to your microcontroller target and one for receiving responses from your microcontroller target. This means that all you have to do is pick two CAN identifiers that are not reserved by the CANopen protocol specification. The unreserved CAN identifier ranges in the CANopen protocol specification are:
- 0x002 – 0x070
- 0x077 – 0x07F
- 0x680 – 0x6DF
- 0x6E1 – 0x700
- 0x780 – 0x7FF
Keep in mind that on CAN a lower identifier value equates to a higher bus priority. For firmware updates, my recommendation is to pick relatively low priority CAN identifiers. So a higher identifier value. This way the firmware update barely impacts your active network and only affects the node undergoing the firmware update. Taking this into account, the following two CAN identifiers meet this recommendation:
- CAN identifier 0x680 for sending XCP commands to the microcontroller
- CAN identifier 0x780 for receiving XCP responses from the microcontroller
To configure this set of CAN identifiers, all you have to do is change two macro values in the bootloader’s configuration header-file “blt_conf.h”:
Alternatively, you could configure 29-bit extended CAN identifiers. CANopen only reserves 11-bit CAN identifiers. This way you know that your CANopen bootloader stays compatible with the CANopen network, even if the CANopen protocol specification changes the reserved CAN identifier ranges in the future.
OpenBLT bootloader in a multi-node CAN network
Note that with a little trick the two CAN identifiers configured for firmware updates are sufficient, even in a CAN network with multiple nodes running the OpenBLT bootloader. The way this trick works is that you can specify an 8-bit node address when establishing a connection with the microcontroller for performing a firmware update. Since CANopen supports node identifiers from 1 to 127, this 8-bit node address suffices for addressing potentially all nodes in the CANopen network for a firmware update. This blog article provides more information on how to configure the bootloader to address a specific node in a multi-node network.
Additional CANopen resources
Given the fact that you read all the way through this article, I conclude that you are interested in the topic of CANopen in general. From that perspective, I would like to finish off this article by giving you a few additional CANopen resources.
The book “Embedded Networking with CAN and CANopen” by Olaf Pfeiffer, Andrew Ayre and Christian Keydel provides a great introduction and in-depth overview into the topic of CANopen. If you are just getting started with CANopen, it falls into the category of must-read in my opinion. When additional details are needed, you can dive into the official CANopen specification documents. The CAN in Automation (CiA) group maintains these documents.
To add CANopen communication functionality to your microcontroller based product, I highly recommend integrating a third party CANopen stack, instead of trying to code one up yourself. There are several proprietary closed source commercial options available. However, given my preference for open source, I would like to suggest the following two open source options:
- CANopenNode. In the past I integrated this communication stack for a few clients. It is a stable and mature CANopen implementation released under the permissive Apache 2.0 license.
- canopen-stack. I haven’t personally worked with this stack yet, but its implementation looks clean and complete. It is also released under the permissive Apache 2.0 license. The added benefit of this solution is that there is a professional company (Embedded Office) behind the stack that offers support. Similar to how Feaser provides professional engineering services around the OpenBLT bootloader.
I sincerely hope you enjoyed reading this article and I wish you the best of luck with your CANopen endeavors.
