Skip to main content
Vinay_Shirol
Vinay_Shirol
Associate II
April 10, 2026
Question

SBSFU - Build Structure

  • April 10, 2026
  • 1 reply
  • 115 views

Hi everyone,

I’m currently working with STM32 Secure Boot and Secure Firmware Update (SBSFU) and integrating it with my custom application. I’m trying to design the project in a modular and scalable way for long-term use, and I would really appreciate some guidance from those who have worked with SBSFU in production.

 Current Scenario

  • MCU: STM32 (Cortex-M series)
  • Bootloader: SBSFU
  • Application: Custom firmware using HAL, middleware, and CubeMX-generated code
  • Development tool: STM32CubeIDE

 Challenges I’m Facing

1. Shared Drivers & Middleware

Both my bootloader and application require:

  • HAL Drivers
  • Some middleware components

 What is the best way to manage duplication vs sharing?

  • Should bootloader and application maintain completely separate copies of Drivers/Middleware?
  • Is there any recommended way to keep them in sync without tight coupling?

 2. Impact of .ioc Changes

I use CubeMX via .ioc for peripheral configuration.

If I:

  • Add a new peripheral
  • Modify clock or pin configuration

How should this be handled without breaking SBSFU?

  • Should bootloader and application always have separate .ioc files?
  • Any best practices to avoid regeneration issues affecting secure boot?

3. Folder Structure for Maintainability

What is a recommended folder structure for:

  • SBSFU Bootloader
  • User Application
  • Shared interfaces (if any)

Goal:

  • Easy reuse across projects
  • Clean separation of responsibilities
  • Minimal integration issues

4. Crypto / Encryption Flexibility

I may want to experiment with different encryption schemes in the future.

What is the best way to:

  • Abstract crypto implementation in SBSFU?
  • Replace or extend existing encryption (e.g., AES-GCM)?

Are there any extension points/hooks provided in SBSFU for this?

5. Project Integration in CubeIDE

What is the recommended workflow to:

  • Import SBSFU and Application projects into CubeIDE
  • Manage them as separate or linked projects
  • Build and flash step-by-step (bootloader + application + secure image)

6. References / Best Practices

Could you please suggest:

  • Application notes
  • Reference projects
  • Real-world examples

especially for:

  • Clean SBSFU + Application separation
  • Maintainable architecture
  • Production-ready setups

 Goal

To build a robust, reusable, and scalable secure firmware update architecture using SBSFU that can support:

  • Future feature additions
  • Crypto changes
  • Multiple applications

Any insights, architecture suggestions, or real-world experiences would be extremely helpful.

Thanks in advance!

1 reply

Pavel A.
Pavel A.
Super User
April 10, 2026

Which STM32 MCU do you use? Different STM32's have different security mechanisms for SBSFU. If not decided yet, can you tell more about the requirements, this will help to choose the MCU.

> Should bootloader and application maintain completely separate copies of Drivers/Middleware?

Most likely yes. Because, with "hiding protection", when the app starts, the bootloader code "disappears" and cannot be called from the app. So you don't have to arrange for sharing any runtime code. The projects can be separate. Sharing the drivers & middlewares source code, of course, is possible.

> Should bootloader and application always have separate .ioc files?

Of course, hardware & clock settings of the bootloader and the app should be "harmonized" so that the app won't have to undo what the bootloader did. Basically, the bootloader sets up the environment for the app: if the app runs in external memory, it must be initialized with all dependencies (power, clocks) and the app obviously should not touch these settings in their startup code.

Outside of that, the app is free to enable and set up additional pins, peripherals etc. So if you later change the .ioc to add stuff for the app, you won't have to regenerate the code for bootloader. The same with multiple apps: different apps may need different changes in the .ioc, but as long as these changes do not affect the bootloader - no problem.

For experimenting with crypto methods you can use software simulators or Linux on ARM machines such as Raspberry Pi etc.

Good luck.

Terms & ConditionsAccessibility statement