Download FW file to NOR flash : SBSFU 2.4.0

[ANaga.2]

Hi,

Thanks for releasing the SBSFU version 2.4.0.

Could you please let me know if it possible in this version to download the FW file to NOR flash.

I would like to use NOR flash as Download slot.

If it is possible, could you please give me an short overview on how can I achieve this.

Thanks,

Ankush

[Jocelyn RICARD]

Hello Ankush,

You can look at the example:

STM32CubeExpansion_SBSFU_V2.4.0\Projects\B-L475E-IOT01A\Applications\2_Images_ExtFlash

This example is also showing the usage of 2 active slots.

Best regards

Jocelyn

[ANaga.2]

Thats wonderful. Thank you Jocelyn

[ANaga.2]

Hi Jocelyn,

This example project had all the information I wanted. Thank you so much.

I could integrate and successfully download the firmware to NOR flash. But during the installing of new firmware, the system is getting stuck at the point "e_ret_status = PrepareCandidateImageForInstall(DwlSlot, &fw_image_header_to_test); in the function SFU_IMG_TriggerImageInstallation.

I assume this could be because of hardware fault. Could you please let me know what could be the reason.

Thanks,

Ankush

[Jocelyn RICARD]

Hello Ankush,

this is time to start your debugger and see what is blocking !

Just deactivate all protection in app_sfu.h if not already done, and break when you do not see any more change in trace.

You should see where you are in stack frame and be able to identify the root cause of your issue

Best regards

Jocelyn

[ANaga.2]

I found from where the problem is coming. It is failing at the function VerifyFwSignatureScatter.

The memory compare is failing. Here it is doing the comparison between fw_tag_output and fw_tag. Both these 32 byte blocks have different values, so the failure.

I don't know why this is happening. I will dig deeper and see what could be the problem.

If you have any hints, please let me know.

Thanks,

Ankush

[ANaga.2]

I assume this could be the RAM reservation issue. _estack is different for SBSFU and user application.

For USERAPP:

/* Highest address of the user mode stack */

_estack = 0x2000D000;

For SBSFU:

/* Highest address of the user mode stack */

_estack = 0x2000C000;

This is the only difference between both the projects in Linker files. If I keep 0x2000C000 for userApp, memory overflow occurs and if I keep 0x2000D000 for SBSFU project, system goes to endless loop and stuck in SE_Init()

[Jocelyn RICARD]

Hello Ankush,

Well, here the tag means the hash of the firmware.

For some reason, the hash you computed with the prepareimage tool is not that same as the one you compute on the target.

The stack location has nothing to do with this.

The SBSFU uses a stack in RAM when executing, but when launching the application, this stack used by SBSFU, as well as all RAM used by SBSFU becomes available to application.

Only possible issue with this would be related to some stack overflow in SBSFU, writting into RAM location used for other purpose...

but usually this leads to a crash :)

Just put the stack as high as possible in memory, just to be sure issue does not come from this.

Best regards

Jocelyn

[ANaga.2]

Hi Jocelyn,

I investigated something. I think this invalid tag is because of using external flash for downloading FW.

When I changed it to internal flash, valid tag was received and SBSFU continued with swapping and successful installation. When I changed back to external flash, the issue occurs.

Your hints on solving this are really helpful !!

[ANaga.2]

Okay. I am using the same SECBOOT_ECCDSA_WITH_AES128_CBC_SHA256 crypto scheme at both the sides. I am really not sure why the hash computed is different :(

Regarding using the higher stack, I am using projects from STM32L432KC for STM32L452 controller by changing the linker descriptions. If I increase the stack from 0x2000C000(end of RAM in L432) to 0x20028000 (end of RAM in L452) in linker description of SBSFU project, The SBSFU hangs at the callgate function inside SE_Init(). From here I cannot debug because it is from different project (SECoreBin project).

[ANaga.2]

It worked finally !! :)

I was using 64 bytes sector erase during the external erase operation. For some reason it was erasing whole download area after decrypting the image which resulted in wrong tag.

After changing it to 4bytes sector erase it is working as expected and we finally integrated SBSFU 2.4.0 to our application which uses external flash to download FW. Thanks for your support :)