Port fails on __IS_SFU_RESERVED()

[Arno1]

Hi,

I've been trying to port the STM32H753 SBSFU project to the STM32H735G-DK.

The bootloader fails in SFU_BOOT_Init due to failing SE_Init().

This is the result of __IS_SFU_RESERVED() failing it's test:

0x08008A00 < 0x08008061 < 0x0801FFFF (SB_REGION_ROM_START < __get_LR() < SB_REGION_ROM_END).

As you can see the LR register value is outside of the expected range.

Does anyone have an idea why this could be the case?

Thanks!

[Jocelyn RICARD]

Hi Arno,

The purpose of this __IS_SFU_RESERVED function is to check that dedicated SBSFU functions are called from SBSFU.

You should check which function is calling SE_Init. This function should be in SBSFU address range.

SE_Init itself should be located in the SE interface address range.

So, only question: what function called SE_Init ?

Best regards

Jocelyn

[Arno1]

Hi Jocelyn,

It fails at start, here is the order of execution:

main.c: main
sfu_boot.c: SFU_BOOT_RunSecureBootService
sfu_boot.c: SFU_BOOT_Init
se_interface_bootloader.c: SE_Init
Fails here

Could it be the SBSFU is somehow loaded in the wrong range?

Best regards,

Arno

[Arno1]

I should add that the address from which the init is called comes from something called 'SB_HDP_region_ROM'. I'm not sure what that area is for and why the init code is loaded in that segment.

[Jocelyn RICARD]

Hi Arno,

This region is used to store code that will be copied to RAM. It is used to manage the memory hide protection locking.

 .RamFunc :

 {

  . = ALIGN(8);

  *(.RamFunc)    /* RAM functions to activate HDP */

  . = ALIGN(8);  

 } > SB_HDP_Code_RAM_region AT>SB_HDP_ROM_region

Also it is a very small region:

__ICFEDIT_SB_HDP_region_ROM_end__     = __ICFEDIT_SB_HDP_region_ROM_start__ + 0xFF;

So, this is very strange that your sfu_boot code goes there.

You need to check in your map file what happened during the link process.

Best regards

Jocelyn

[Arno1 · Accepted solution]

I've got it working now. I was trying to find the reason for a hard fault and added some printfs for debugging. These however caused the LR confusion.

The original fault was because I was still building with the older cryptographic library (v3.0.0 I think).

I now have a working port to the discovery board.