cancel
Showing results for 
Search instead for 
Did you mean: 

MCUBoot size

pierre20
Associate II

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

5 REPLIES 5
AScha.3
Chief III

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".
pierre20
Associate II

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.

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".
pierre20
Associate II

What an inappropriate answer.

Thanks buddy, very helpful !

Jocelyn RICARD
ST Employee

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