Last week OpenBLT version 1.4.1 was released. Besides some code refactoring, this patch release features improved support for firmware updates via Controller Area Network (CAN). The improved CAN support is part of the roadmap to version 1.5.0. Several users reported that they have a strong interest in these features. For this reason, I decided to give them high priority and release them early with this patch.
On the host side, CAN support was added to both the OpenBLT host library (LibOpenBLT) and the cross-platform BootCommander program. On the target side, 29-bit extended CAN identifiers support was added.
CAN support in LibOpenBLT
LibOpenBLT is a cross-platform host library that handles the communication between a PC program and a microcontroller, running the OpenBLT bootloader. It was introduced with OpenBLT version 1.4.0. At that point it only supported RS232 as the communication medium. This patch introduces support for CAN as the communication medium. TCP/IP and USB are planned to be added in the not too distant future.
Currently, three popular CAN interfaces are supported in both MS Windows and Linux: Peak PCAN-USB, Kvaser Leaf Light v2 and Lawicel CANUSB. The implementation in Linux is based on the SocketCAN kernel functionality, which means that all SocketCAN compatible CAN interfaces are actually supported.
CAN support in BootCommander
You can now perform firmware updates via CAN with BootCommander. This is great news for those using Linux and for those that prefer the BootCommander command line program over the MicroBoot program that features a graphical user interface. Since BootCommander is built on top of LibOpenBLT, all that had to be done was to implement a few more command line options, allowing the user to configure the CAN based transport layer. To see these new options, simply run the BootCommander program without specifying any command-line options:
Alternatively, you can find a description of these options on the BootCommnander Wiki-page.
Here is a step-by-step BootCommander example on how to perform a firmware update via CAN. The example is for Linux, to briefly demonstrate how to bring up the SocketCAN link as well. On the target side, an Olimex STM32-P405 board was using, running the OpenBLT demo bootloader programs. For the CAN interface a Kvaser Leaf Light v2 was used.
Step 1 – Bring up the SocketCAN link
Connect the Kvaser Leaf Light v2 and check its interface name. You can use the ‘ip addr’-command for this. It is most likely ‘can0’, which will be used in this example. Run the following commands as super user (sudo) to configure the link for a 500 kbit/sec CAN baudrate and to bring it link:
modprobe can modprobe can_raw ip link set can0 type can bitrate 500000 restart-ms 100 ip link set up can0
Step 2 – Perform firmware update with BootCommander
The Olimex STM32-P405 demo bootloader is pre-configured to support CAN at the same 500 kbit/sec CAN baudrate. You can find these settings in the bootloader’s “blt_conf.h” configuration header file. There you can also see that the CAN identifier for command messages is 0x667 and for response messages is 0x7E1.
These configuration settings happen to be the defaults for BootCommander as well, so they don’t need to be explicitly specified. To perform the firmware update via CAN, simply run the following command:
./BootCommander -t=xcp_can -d=can0 demoprog_olimex_stm32p405.srec
Alternatively, if you want to specify all possible CAN related command line options:
./BootCommander -t=xcp_can -d=can0 -c=0 -b=500000 -tid=667 -rid=7e1 -xid=0 demoprog_olimex_stm32p405.srec
Note that the “-b=<value>” baudrate option is don’t care under Linux, because the baudrate is already configured when bringing up the SocketCAN link.
29-bit extended CAN identifiers
During a firmware update with the OpenBLT bootloader, two CAN identifiers are utilized. One for sending commands from the host (PC) to the target (microcontroller) and one for sending responses back the other way. Previously, only 11-bit CAN identifiers could be used for this. Since this patch release, 29-bit CAN identifiers are also supported.
On the target side, the use of 29-bit extended CAN identifiers is configured by OR-ing the CAN identifier with bitmask 0x80000000, in the ‘blt_conf.h’ configuration header file. In other words, set the 32nd bit to 1 in the CAN identifier:
On the host side, it depends if you are using BootCommander or MicroBoot. With BootCommander you add the ‘-xid=1’ command line option. With MicroBoot, you enable the checkbox ‘Use Extended IDs’ in the settings:
After reading this article, you should have a good understanding of how to use the new CAN functionality in OpenBLT. As always, feedback is welcome. Let me know if you are using a different CAN interface than what is currently supported. Support for additional CAN interfaces can be added upon request.
