cancel
Showing results for 
Search instead for 
Did you mean: 

STM32CubeU5 TFM swap strategy, secure loader

ppedro
Associate II

Hello,

I am working with STM32CubeU5 TFM v1.5 for STM32 u585. I develop a custom loader using CAN communication. First I used MCUBOOT_OVERWRITE_ONLY and MCUBOOT_PRIMARY_ONLY setup. The CAN communication worked fine (in non-secure loader).

Then I switched to swap strategy (MCUBOOT_OVERWRITE_ONLY and MCUBOOT_PRIMARY_ONLY not defined). The CAN communication stopped working. After quite some investigation I found out that the reason is that the FDCAN IRQ is not enabled (although set to be enabled). Then I found out that the reason is probably due to the FDCAN1_IT0_IRQn is not set in ITNS1 for the non-secure domain. This can be handled in the secure loader.

Unfortunately, in this mode the secure loader is not used. I am not sure why, did I misconfigure or misunderstand something? 

Any advise how to get interrupt enabled in the the non-secure loader in this mode?

Thanx.

Best regards,

peter

1 ACCEPTED SOLUTION

Accepted Solutions
Jocelyn RICARD
ST Employee

Hello @ppedro ,

following OLS case you made, I shared with you a working project that re-enables the secure loader to be able to make necessary configuration for your loader and with non secure loader size increase.

I also created an internal case to get back this secure part of the loader whatever the configuration.

I hope this will fit your needs

Best regards

Jocelyn

 

View solution in original post

5 REPLIES 5
ppedro
Associate II

Hello,

it is the postbuild.sh script (loader) that switches if to include the secure loader in the loader image. It is size of secure_nsclib.o that switches one or the other way.

I forced to skip this and got an error when flashing the loader.bin:

Erasing memory corresponding to segment 0:
Error: Operation exceeds memory limits

I see two ways to go:

- playing with loader (secure / non-secure) sizes to fit into limits

- making loader pure secure implementation

Please, let me know if I am mistaken in my observations and what ways out you see?

Thanx.

Best regards,

peter

ppedro
Associate II

Hello,

I tweaked with the ns loader size and managed to decrease it. I came to some limits that I cant decrease any more. 

Looking at the UM2851, Memory layout for the swap mode, Figure 10 shows:

ppedro_0-1712657741546.png

Non-secure local loader space available is 24 kB. Below that is Unused 112 kB. Is there a way to use this unused space and thus having 136 kB for the non-secure local loader?

Best regards,

peter

ppedro
Associate II

Hello again,

in order to summarize my problem and questions / help I need to resolve it is as follows:

  • we want to use swap mode in FW update
  • my custom loader (using CAN communication) is not possible to get smaller than 24kB that is size of area for a non-secure loader
  • when a bigger non-secure loader is used then the secure loader is not used (postbuild.sh script probably knows it is doing so)
  • the size of non-secure loader is not a problem but then the security features (split of resources for secure / non-secure domains) is not where to set up. MCUboot?

Thus I need to answer the following:

  • how to increase area for non-secure loader and still the secure loader to be present? There is 112kB of unused space just next to it.
  • where alternatively setup security features when the secure loader is not present?

Or please correct me if my observations / findings / understandings are wrong.

Any help / advise is highly appreciated.

Thanx.

Best regards,

peter

Jocelyn RICARD
ST Employee

Hello @ppedro ,

following OLS case you made, I shared with you a working project that re-enables the secure loader to be able to make necessary configuration for your loader and with non secure loader size increase.

I also created an internal case to get back this secure part of the loader whatever the configuration.

I hope this will fit your needs

Best regards

Jocelyn

 

ppedro
Associate II

Hello Jocelyn,

thanx for the solution you made in OLS case. It's working as expected.

Thanx.

Best regards,

peter