Skip to main content
Associate
January 13, 2025
Question

MCUBoot size

  • January 13, 2025
  • 4 replies
  • 4351 views

Hi,

I'm currently exploring the solutions to develop a bootloader on a STM32U535. I'm looking into the MCUBoot based examples provided by ST : SBSFU projects.

After some investigations, I noticed that the SBSFU_Boot memory footprint was ~80ko and the SBSFU_Loader one was 24ko. For MCUs with limited flash size like STM32U535xB, this leaves almost no space for the application.

Is there a way to reduce MCUboot size ? For instance, by disabling non essential modules ?

Or maybe am I doing something wrong and memory footprint should be lower ?

Pierre

4 replies

AScha.3
Super User
January 13, 2025

Hi,

the STM32U535 has built in bootloader , also on USB .

So 128K for your program,  see AN2606 ...

or why you want make the bootloader yourself ?

"If you feel a post has answered your question, please click ""Accept as Solution""."
pierre20Author
Associate
January 14, 2025

The built in bootloader is too simple, I need the security features of SBSFU : image encryption / decryption, reset recovery, downgrade prevention.

My question was poorly asked, I'm not trying to develop a bootloader from scratch. I'll use MCUBoot because I need these security features and I'm trying to understand its flexibility. 

And I was wondering if, for limited size MCUs, there were ways to optimize MCUBoot memory footprint, in order to leave more space for the application.

AScha.3
Super User
January 14, 2025

Ah, ok...so its a problem about money, because the 512KB version is about 40 ct more expensive.

Thats dramatic  then...

"If you feel a post has answered your question, please click ""Accept as Solution""."
pierre20Author
Associate
January 14, 2025

What an inappropriate answer.

Thanks buddy, very helpful !

Jocelyn RICARD
ST Employee
January 22, 2025

Hello @pierre20 ,

On STM32U5, the secureboot solution is designed to be run with TrustZone enabled. Secure configuration is needed and possibly 2 applications, secure + non secure which may increase size used.

Also, it is based on mcuboot which uses mbedTLS for cryptography.

This is not very optimized solution especially if you use a part without crypto acceleration (which reduces a bit the footprint)

Anyway, 128KB flash is really too small for such solution.

Possible solutions I can see:

1) build your own secure boot: this is possible but time consuming

2) port the X-CUBE-SBSFU solution. It is a bit more optimized in footprint. Again this may take some time

3) use a third party solution. For instance Wolfssl proposes a secure boot solutions that looks smaller in first glance

Best regards

Jocelyn