cancel
Showing results for 
Search instead for 
Did you mean: 

Adding MCUBoot and secure boot feature into system memory bootloader firmware upgrade

wesleywong
Associate II

Hi ST team,

I am using STM32U5G9 as secondary MCU. It has simple firmware upgrade feature. It would be reset by main MCU and enter system memory bootloader using Boot0 pin. The system memory bootloader would receive upgrade image (application) from main MCU by USART and write the image into internal flash. (AN3155 and AN2606)

This method is simple but it does not have any sercrity feature. I would like to ask if I could add MCUBoot and secure boot into this method with minimum effort?

1. System memory bootloader would receive signed image (application) from main MCU and write it into non-secure area.

2. Exit system memory bootloader and enter secure boot

3. Secure boot verifies the authenticity and integrity of the application.

4. Execute the application.

Is this possible? 

1 ACCEPTED SOLUTION

Accepted Solutions

Hello @wesleywong ,

I'm sorry for late reply.

First what you suggest is possible. You can program the non secure area when device is in RDP 0.5

But this is not a "secure" way of updating your firmware.

This mechanism is more used in development mode when you provide a device with only secure part programmed and development is made on non secure, possibly using secure services.

There is a firmware update example available. You can find this SBSFU example as an example application of the STM32U585 for instance.

This example allow a setup with secure update using one slot. This example still requires having a secure application and a non secure application. They can be concatenated or not.

The update is using a provided standalone loader applicaiton. So basically you would have a setup like:

SBSFU at beginning of the flash

Secure application

Non secure application

Loader at end of the flash

You jump in the loader through the SBSFU. So, you can trigger the update either through external button read by SBSFU at boot, or through a magic written in RAM by application, reset, SBSFU checks the magic and jumps to loader if requested.

Best regards

Jocelyn

View solution in original post

3 REPLIES 3
Jocelyn RICARD
ST Employee

Hello @wesleywong ,

This setup is not possible as long as you enable flash protection with RDP.

The system bootloader will refuse to write into the flash.

You have a secure boot example in the STM32CubeU5. It is using a Ymodem protocol to download the new binary.

Best regards

Jocelyn

Hi @Jocelyn RICARD ,

I am sorry I am not fimilar with Trustzone, MCUBoot and secure boot. Would they block the access of system memory bootloader?

If I enable RDP level 1 and WRP. Could system memory bootloader disable WRP and then regress RDP to level 0.5 by command?

After regressing RDP to level 0.5, the non secure area would be erased. Then it could perform the firmware upgrade process I mentioned above.

And then enable WRP and restore RDP level  by change option byte in secure boot/application.

Screenshot 2025-10-23 121419.png

Screenshot 2025-10-23 122002.png

 

If it is not possible, could you provide an firmware upgrade example (SBSFU?) or application notes that using single slot for STM32U5?

I was using system memory bootloader for firmware upgrade because the image size is larger and could not use dual bank method.

Thank you.

Hello @wesleywong ,

I'm sorry for late reply.

First what you suggest is possible. You can program the non secure area when device is in RDP 0.5

But this is not a "secure" way of updating your firmware.

This mechanism is more used in development mode when you provide a device with only secure part programmed and development is made on non secure, possibly using secure services.

There is a firmware update example available. You can find this SBSFU example as an example application of the STM32U585 for instance.

This example allow a setup with secure update using one slot. This example still requires having a secure application and a non secure application. They can be concatenated or not.

The update is using a provided standalone loader applicaiton. So basically you would have a setup like:

SBSFU at beginning of the flash

Secure application

Non secure application

Loader at end of the flash

You jump in the loader through the SBSFU. So, you can trigger the update either through external button read by SBSFU at boot, or through a magic written in RAM by application, reset, SBSFU checks the magic and jumps to loader if requested.

Best regards

Jocelyn