Issue building SBSFU with latest STM32CubeIDE 1.9.0 : here is the solution

[Jocelyn RICARD]

Hello SBSFU users !

The latest release of STM32CubeIDE 1.9.0 is introducing GNU Tools version 10.3 as toolchain. This new toolchain creates an issue in the SBSFU final build.

A new release of X-CUBE-SBSFU is coming in around one month to fix this but, in the meanwhile, I would like to share with you the changes needed to be able to use this version of STM32CubeIDE.

First, the issue is related the the ability to call services in the secure engine. So, if you do not need this feature, just remove it.

Here is how to do this.

1- Open Properties of your user application

2- in C/C++ Build/Settings/MCU GCC Linker/Miscellaneous, remove the content of Additional objects. Something like "./../../2_Images_SBSFU/STM32CubeIDE/Debug/se_interface_app.o"

3- Also remove in your code any call to SE_*. The common service implemented is usually SE_APP_GetActiveFwInfo

That's it.

Now, if you use the SE service, here is what you need to do. The following is the description of the changes done in the SBSFU provided in the STM32WL firmware package. So, you can also get this package for reference.

Principle is to generate a specific .ld file containing the service name and associated address.

1) In SBSFU project, you need to create a postbuild.sh ...SBSSU/STM32CubeIDE/postbuild.sh containing the following

#!/bin/bash -
echo "Extract SE interface symbols"
arm-none-eabi-nm $1 > nm.txt
case "$(uname -s)" in
    Linux*|Darwin*)
      tr -d '\015' <../se_interface.txt >../se_interface_unix.txt
      grep -F -f ../se_interface_unix.txt nm.txt > symbol.list
      rm ../se_interface_unix.txt
      ;;
    *)
      grep -F -f ../se_interface.txt nm.txt > symbol.list
      ;;
esac
wc -l symbol.list
cat symbol.list | awk '{split($0,a,/[ \r]/); print a[3]" = 0x"a[1]";"}' > se_interface_app.ld
rm nm.txt
rm symbol.list

2) Add the call to this postbuild.

in Properties/C/C++ build/Settings/Build Steps/Post-built steps

Replace the old command by this new one:

"../postbuild.sh" "${BuildArtifactFileName}"

This will create the se_interface_app.ld in the debug directory

When building SBSFU you should see something like this in the build console. The 1 means only 1 symbol created. This is the number of services of Secure Engine you use. 

Extract SE interface symbols

1 symbol.list

3) Edit the .ld file of your application and just before the INCLUDE mapping_fwimg.ld add following line

INCLUDE se_interface_app.ld

4) Last point. You need to give to linker the directory where to find this ld file

in Properties/C build/Settings/MCU GCC Linker/Library/Library search path, add following line

 ../../../2_Images_SBSFU/STM32CubeIDE/Debug

You may need to adapt the path to your own project to find the path to SBSFU

Then your application should link.

I hope this will help

Best regards

Jocelyn

[Kevin Lang]

Okay, I got it , I missed one step

[Kevin Lang]

Hello,

I created my own App and modified postbuild.sh

After downloaded app , installed it, run it, I got an error: Memory Fault.

What shall I do to fix the issue?

Many thanks,

...

INFO: A Reboot has been triggered by a Software reset!

= [SBOOT] STATE: CHECK NEW FIRMWARE TO DOWNLOAD

= [SBOOT] STATE: CHECK USER FW STATUS

     A FW is detected in the slot SLOT_ACTIVE_1

= [SBOOT] STATE: VERIFY USER FW SIGNATURE

= [SBOOT] STATE: EXECUTE USER FIRMWARE

     Memory fault

========= End of Execution ==========

[firmwareguru]

Adding a bit of background to this issue.

This is not a bug in the SBSFU but an issue introduced with ld in binutils 2.36 included with the updated toolchain with STM32CubeIDE 1.9.0. In particular, a check was added to the ld linker to reject input elf/object files that have the type attribute ET_EXEC. This check was added as a result of this (supposed) binutils issue. It must be noted that the standard .elf output for microcontroller/embedded systems projects (at least for ARM cortex-M) builds static "executables" with the ET_EXEC type set. This issue raises the possibility that there are use cases for linking with ET_EXEC type elf files. I think this "feature" remains present after 2.36 although there may be linker options available to suppress the check that one could use in their project as a workaround.

In any event, Jocelyn's solution is elegant because it simplifies the SBSFU build and application binding process by avoiding the need to generate an object file to link with. Since se_interface_app.o just provides the SECoreBin function addresses and not any code, it makes sense to explicitly enumerate them in a linker script somewhere.

The stm32-secure-patching-bootloader, which offers additional features of firmware patching, USB flash drive updating and TouchGFX update capability, will implement this style of fix in the v1.3 release. In the meantime the v1.2.1 release implements a work-around that works with the STM32CubeIDE 1.9.0 toolchain.

[kaur]

Hi Jocelyn, 

Does the latest version of SBSFU still use se_interface_app.o file. I don't see any way to generate this file in latest codebase but UserApp linker file still uses it. Do I need to use  the output files se_interface_application.o, se_interface_bootloader.o, se_interface_common.o instead. I am using the project for 2_Images under STM32CubeExpansion_SBSFU_V2.6.2/Projects/P-NUCLEO-WB55.Nucleo/Applications/2_Images but the format is same across all projects.