Dual Bootloader with FDCAN Firmware Update and CRC Validation on STM32G0B1CCT6

[AKG123]

I am working on a custom dual-boot bootloader for the STM32G0B1CCT6 with the following features:

• Bootloader located at 0x08000000 (about 20 KB flash).

• Two application firmware slots:

  • App1 at 0x08005000 (22 KB)

  • App2 at 0x0800A800 (22 KB)

• On reset, the bootloader checks the CRC of App1 and App2 firmware:

  • If App1 is valid, it jumps to App1.

  • Else if App2 is valid, it jumps to App2.

  • Else it stays in bootloader mode.

• Firmware updates are sent via FDCAN as .bin files (no special commands, just the binary data).

• The bootloader receives the firmware, writes it to the free app slot, verifies CRC:

  • If CRC passes, it overwrites the old firmware and jumps to the new app.

  • If CRC fails, it keeps the old firmware and stays in bootloader mode.

• I want to support multiple firmware updates this way reliably.

I have basic HAL code generated from CubeMX for FDCAN and CRC peripherals.

My questions:

1. Is my memory layout and CRC validation approach suitable for STM32G0B1CCT6 with 64KB flash?

2. How can I best implement the FDCAN reception to reliably receive large .bin files chunked over CAN FD?

3. Are there any reference projects or examples from ST that implement similar dual-bootloader with CRC check and FDCAN update?

4. Any tips on safely erasing and writing flash while receiving firmware over FDCAN?

5. How do I store and update CRC metadata securely in flash?

6. How to properly jump from bootloader to application and manage vector tables?

[Abdul-khalil]

Problem Statement:

I am developing a custom bootloader for the STM32G0B1CCT6 microcontroller that supports the following functionality:

1. Dual Boot Mode:

   • The bootloader is programmed via ST-LINK V2.

   • The application firmware is uploaded later via FDCAN in .bin format.

2. CRC Validation:

   • On every power-up or reset, the bootloader checks the CRC of the existing application firmware.

   • If the firmware is valid (CRC matches), the bootloader jumps to the application.

   • If the firmware is invalid (CRC mismatch or corrupted), the bootloader remains active and does not jump.

3. Firmware Update via FDCAN:

   • The bootloader receives the new .bin file via FDCAN (without waiting for any specific command/message).

   • After receiving the complete firmware, it calculates the CRC and verifies it.

   • If the new firmware is valid, the bootloader erases the previous one and flashes the new firmware.

   • If the new firmware is invalid, the old firmware remains untouched and continues to run.

4. Repeatable Process:

   • I should be able to update the firmware multiple times via FDCAN.

   • Each time, CRC is verified before replacing the existing firmware.

Goal:
To ensure reliable firmware updates via FDCAN, with automatic CRC verification and fallback to the previous valid firmware if the update fails or is corrupted.

[Saket_Om]

Hello @AKG123 

Please refer to the open bootloader example below.

STM32CubeG4/Projects/NUCLEO-G491RE/Applications/OpenBootloader at master · STMicroelectronics/STM32CubeG4 · GitHub