The modern automobile is a marvel of engineering, but at its heart, it’s a complex network of computers. These computers, known as Electronic Control Units (ECUs), control everything from your Motor Controller to your airbags in any Electric vehicle. And just like any computer, the software running on these ECUs needs occasional updates.

Imagine you could update your vehicle’s software as easily as downloading a new app on your phone. In the automobile industry, that’s becoming increasingly possible thanks to bootloaders, and a key player in this process is the Controller Area Network (CAN) bus.

What’s a Bootloader?

Think of a bootloader as the gatekeeper for your vehicle’s Electronic Control Units (ECUs), the mini-computers that manage everything from the Motor Controller to the Display Cluster in Electric Vehicles. This tiny program runs at startup and loads the main ECU software. But here’s the cool part: bootloaders also allow reprogramming of that software.

CAN: The Information Highway

Now, how does the update get to the bootloader? That’s where CAN comes in. CAN is a communication protocol that acts as the internal network for ECUs.  Using CAN messages, a diagnostic tool can securely send new software to the bootloader, which then takes care of flashing it onto the ECU’s memory.

Benefits of CAN-based Bootloaders

• Remote Updates: Imagine fixing a software bug or improving EV performance without a trip to the mechanic. CAN-based bootloaders enable remote updates, keeping your vehicle running at its best.
• Security: CAN offers a robust communication layer, making it difficult for unauthorized access during updates.
• Flexibility: Bootloaders allow for staged rollouts of new features or bug fixes, ensuring a smooth transition for vehicle owners.

At Vecmocon, We use CAN-based Bootloaders to remotely push the updates using iVec-IoT in our customer’s Battery Management Systems for further enhancing, custom configuration, and resolving any issues. Customers who do not use our IoT devices still benefit from CAN-based Bootloaders during the R&D, Testing, and Integration phase of Battery Pack Development.

Designing a CAN-based Bootloader: Key Considerations

Developing a CAN bootloader requires careful consideration of several factors:

• Size Constraints: Bootloaders typically reside in limited ECU memory. Code size optimization is crucial for efficient operation.
• Reliability and Error Handling: The bootloader must handle potential errors during the update process, like communication failures or corrupted data packets. A robust recovery mechanism is essential.
• Security Measures: The bootloader should implement authentication mechanisms to accept only authorized firmware updates. Encryption can further safeguard data integrity.
• Flexibility and Futureproofing: The bootloader design should be adaptable to support future software updates and potential hardware upgrades within the ECU.
• Parallel / Multi-Target Update: The bus can have multiple assets on the same can bus(Parallel Battery) or different assets with the same bootloader protocol.

The bootloader is organized into three layers: 

• Bootloader(BSW Layer) – is in charge of starting the user application and polling for incoming data. 
• Communication handling / Memory handling(ECU Layer) – is in charge of processing the received data and handling the writes to non-volatile memory. 
• Microcontroller drivers(HAL Layer) – are in charge of handling all the low-level communication with the actual peripherals available on the microcontroller. 

Firmware update methods

To update the firmware in a microcontroller, either of two methods is followed. These two methods are the a/b approach and the in-place approach. 

In-place approach has been used. In this method, the microcontroller only stores one firmware image, which might occupy all the available flash memory. In this case, the update cannot be done while the microcontroller is running and if the update process did not finish correctly it can be difficult to recover the old image.

The a/b swap approach refers to when the microcontroller stores two images in separate flash regions. In this case, it might be possible to do the firmware update of one region while the microcontroller is running. Since the microcontroller stores two different firmware, the old firmware and the updated one, it is possible to instantly recover in case the new firmware does not work correctly. The main disadvantage is that two application images should fit in the microcontroller’s NVM, therefore reducing the maximum firmware application size. Another challenge in this method is the firmware remapping since there are two applications in different physical addresses of the NVM.

Bootloader workflow overview

1. The first step is to initialize the available communication channels. Communication interfaces can be enabled to work simultaneously, but since the bootloader is optimized for size, the bootloader’s linker file would have to be modified to accommodate the generated code. Therefore, it is recommended to use only one kind of communication at a time.
2. The second step is to initialize the timeout mechanism. After a reset, the microcontroller will poll the selected communication channel, if no activity was detected during the time allowed by the timeout mechanism the device will attempt to execute the last application loaded, if the device hasn’t received an application it will get stuck in a loop. To attempt the download of an application another reset is required. 
3. If a timeout occurs or an application is flashed to the device, the bootloader must disable all peripherals initiated at the init of the bootloader. This step is required to ensure the application starts executing on an environment close to of reset state. 
4. Once the device has been set to its reset state the device attempts to jump to the user application.

The following figure showcases the memory layout that the bootloader and the application can follow. Keeping Bootloader Vectors at the start of Memory makes sure on device reset, the bootloader code executes first. Dividing the bootloader into two different locations gives the flexibility of using different memory locations like D-Flash. The designer of software architecture must update the linker file accordingly.

By carefully addressing these factors, engineers can create CAN-based bootloaders that ensure smooth, secure, and reliable software updates for the ever-evolving automotive landscape.

The Road Ahead

CAN-based bootloaders are revolutionizing the way vehcile software is updated. As vehicles become increasingly complex and software-driven, these tiny programs will play a vital role in ensuring safety, performance, and a truly connected driving experience.

Further Exploration:

This blog is just a starting point. If you’re interested in learning more, you can explore topics like:

• Unified Diagnostic Service (UDS): The communication standard used for ECU diagnostics, including bootloader interaction.
• Flash Bootloader (FBL): A specific bootloader commonly used in automotive ECUs.
• Security Considerations: How vehcile manufacturers ensure safe and secure software updates.

So, the next time you hear about a software update for your vehicle, remember the silent hero behind the scenes: the CAN-based bootloader, making sure your vehicle stays up-to-date and on the road.