The OpenBLT 1.17.0 release was made today, after another half year of development work. 15 tickets were processed, which resulted in 74 commits. Feel free to download the new version of the OpenBLT bootloader and give it a try. This release is on track with the standard release cycle. This article describes in more detail what you can expect from the new OpenBLT release.

“Modbus-RTU and new ports” best summarizes the new OpenBLT release. A few highlights:

• The PC tools and all microcontroller ports now support firmware updates via Modbus-RTU.
• Improved accuracy for the internally used software timer.
• New Infineon TriCore TC2 and ST STM32C0 ports, including demo programs.

Modbus-RTU support

Over the past years, several customers requested an OpenBLT customization to support firmware updates using the Modbus-RTU protocol on an RS232 or RS485 communication link. To better serve these customers and future users, I implemented full support for firmware updates via Modbus-RTU in OpenBLT version 1.17.0.

The Modbus protocol origins all the way back to the late 70s and was historically popular for interconnecting electronic devices in the fields of factory and building automation. However, its application goes way further than that. Essentially, you can rely on Modbus anytime you require remote access to the inputs and outputs of a microcontroller. To name a few examples:

• I/O expander for a PC or embedded Linux device.
• Inter-communication between multiple microcontrollers on the same PCB or in the same system.

The elegant Modbus protocol strikes that perfect balance between simplicity and versatility. Even though newer and competing communication protocols exist, rest assured that Modbus will play a role as long as microcontrollers feature a UART peripheral. And I don’t see those disappearing anytime soon, if ever.

Firmware updates on Modbus-RTU

The Modbus protocol itself does not feature function codes for performing a firmware update. Its main focus is on remote access of I/O and some diagnostics. However, the Modbus protocol allows an extension using custom user function codes. Essentially, by using a “user function code” you can step away from the coil, input/holding register type paradigm and embed data however you prefer. This works great for a custom extension such as performing firmware updates via Modbus-RTU.

I selected custom user function code 109, to embed the XCP packets of OpenBLT’s default communication protocol. An illustration of how such an embedded XCP packet looks on Modbus-RTU:

The format of the XCP packet inside the PDU’s data field, resembles how an XCP packet normally gets communicated via RS232. So first a byte with the length of the following actual XCP packet. In essence, this extra length byte could be omitted, because Modbus RTU’s 3.5 character timeout signals the end of a packet. This is not practical when receiving packets on the PC though, where measuring the 3.5 character timeout is not that accurate, resulting in longer delays. By looking at the extra length byte, you can more time efficiently determine the completion of a packet reception on the PC side, even though the extra length byte results in a little more communication overhead.

Getting started with firmware updates via Modbus-RTU

I went through great effort to implement support for Modbus-RTU in all the existing microcontroller ports. This basically means that any of the available OpenBLT demo programs can quickly be reconfigured to enable firmware updates via Modbus-RTU. Details on how to configure your bootloader for firmware updates via Modbus-RTU are on this Wiki page.

Furthermore, I dedicated the Nucleo-F446RE demo programs to showcase firmware updates via Modbus-RTU. You can use it as a reference and starting point: demo program code and demo program description.

Automatic bootloader reactivation via Modbus-RTU

For a seamless firmware update experience, it’s nice if your own firmware can detect the request of a new firmware update and then activate the bootloader via a software reset. That way you can bypass manually resetting the board or toggling its power supply. I add this extra functionality to all demo programs.

In the case of Modbus-RTU this means that you would need a Modbus communication stack. Not a big deal, since you probably already integrated one. However, it should also support the configuration of the custom user function code 109, to be able to receive the XCP Connect command, which signals that start of a firmware update. Unfortunately, not all available Modbus software stacks offer this feature.

With this reason in mind, and being smitten by the Modbus protocol itself, I developed the MicroTBX-Modbus communication stack from the ground up. It is a modern Modbus communication stack, targeting microcontroller based embedded systems. Its aim is to be: easy to use, easy to port, high quality, well maintained, stable and flexible. And of course it supports extending it through custom user function codes. It’s is offered under the same dual-licensing model as the OpenBLT bootloader.

You can find MicroTBX-Modbus integrated in the Nucleo-F446RE demo program. Here’s the code snippet of the custom user function callback function, that detects the start of a firmware update, and reactivates the bootloader via a software reset:

uint8_t AppCustomFunctionCallback(tTbxMbServer    channel,
                                  uint8_t const * rxPdu,
                                  uint8_t       * txPdu,
                                  uint8_t       * len)
{
  uint8_t result = TBX_FALSE;

  /* Check if this PDU contains an embedded XCP command:
   * - Function code: 109 (BOOT_COM_MBRTU_FCT_CODE_USER_XCP in the bootloader)
   */
  if (rxPdu[0] == 109U)
  {
    /* Check if this was an XCP CONNECT command. Its expected contents are
     * 4 bytes:
     * - Function code
     * - XCP packet length: 2
     * - XCP connect command id: 0xff
     * - XCP connect mode (slave id): 0..255
     */
    if ((*len == 4U) && (rxPdu[1] == 2) && (rxPdu[2] == 0xFF))
    {
      /* This is a request to connect to the bootloader, so we need to stop
       * our firmware and start the bootloader. This can be done by issuing a
       * software reset. Since this function does not return, there is no need
       * to prepare a response PDU nor update the result.
       */
      NVIC_SystemReset();
    }
  }
  /* Give the result back to the caller. */
  return result;
}

Improved timer accuracy

Each OpenBLT microcontroller port implements a polling based millisecond timer. The bootloader uses this one as a time reference. For example to detect communication or hardware operation timeouts. I realized that the implementation was functional but not always accurate.

Most ports configured a timer peripheral to generate an event in one millisecond. The timer driver then polls for the event flag to determine if a millisecond passed. So far so good. However, some operations such as flash erasing and programming can take longer than a millisecond. Consequently, more than one millisecond could pass, before the bootloader gets a chance to poll for the millisecond flag. So it thinks just one millisecond passed, when in fact several milliseconds could have passed.

The timer implementation of all microcontroller ports were improved to no longer poll for a millisecond event flag. Instead, they now read out a timer’s free running counter value to determine if at least one millisecond passed and if so, how many.

New ports and demo programs

With the release of version 1.17 of the OpenBLT bootloader, the following additions and changes were made to the ports and demo programs:

New ports

• ST STM32C0
• Infineon TriCore TC2

New demo programs

• Infineon AURIX TC275 Lite Kit – Configured for RS232 and CAN firmware updates.
• ST Nucleo-C031C6 – Configured for RS232 firmware updates.
• ST Nucleo-F446RE – Configured for Modbus-RTU firmware updates.

Closing thoughts

The first release of the OpenBLT bootloader dates back to the end of 2011. It took about five years to gain enough interest and traction, to the point that I could commit and focus full-time on the OpenBLT bootloader in 2017. This is now seven years ago and all these years, I’ve been able to cover my living expenses from the proceeds of the OpenBLT project.

With this in mind, I would like to finish these release notes by thanking everyone for showing an interest in the OpenBLT bootloader project. Especially the ones who purchased the OpenBLT commercial license and the ones who keep renewing their support and maintenance contract. It is thanks to you that the OpenBLT project thrives and that is possible for Feaser to continue sponsoring the development and maintenance efforts.