SBSFU-UserApplication-Debugging

Markus Schwarzl · ‎2024-08-30

I'm curious what is the best way to debug a User Application when using SBSFU on a STM32.
Of course the security mechanisms in SBSFU/SECore must be disabled to allow debugging at all and basically just downloading the UserApplication and debug it with e.g. CubeIDE works as the programmer manipulates the PC to start in the application. But the problem is once the application resets (e.g. SW-Reset) it reboots over the Secure Boot and deletes the application as it was not installed correctly via the SFU. This becomes very tricky in case of debugging something that happens on startup!?
I know that flashing the FW via SFU and then only attaching the Debugger is a working option but it becomes plumby if doing repeated code-changes to the application.

Is there any other suggested way to do that?

Jocelyn RICARD · ‎2024-08-30

Hello @Markus Schwarzl,

Here are the different ways to address this

The simplest way is to use the programmer to flash the new signed binary. Then setup debugger to remove the download of application. This adds one step which is a bit annoying.
You may have a kind of configuration that uses one linker file or other depending on usage of SBSFU. You could have one linker file where application starts at beginning of flash and other linker file where application is located in SBSFU slot.
If you want to debug your application in the SBSFU slot, you can develop a small bootloader that replaces SBSFU and just reads the stack pointer address and reset vector of the application and launch it immediately.
You can also add an option in the SBSFU code to bypass the check. But this needs to be well documented to avoid leaving anything at production time.
If you use a STM32 that allows setting the boot address in option bytes, then just update this option byte to the application address

Best regards

Jocelyn

View solution in original post

Jocelyn RICARD · ‎2024-08-30

Hello @Markus Schwarzl,

Here are the different ways to address this

The simplest way is to use the programmer to flash the new signed binary. Then setup debugger to remove the download of application. This adds one step which is a bit annoying.
You may have a kind of configuration that uses one linker file or other depending on usage of SBSFU. You could have one linker file where application starts at beginning of flash and other linker file where application is located in SBSFU slot.
If you want to debug your application in the SBSFU slot, you can develop a small bootloader that replaces SBSFU and just reads the stack pointer address and reset vector of the application and launch it immediately.
You can also add an option in the SBSFU code to bypass the check. But this needs to be well documented to avoid leaving anything at production time.
If you use a STM32 that allows setting the boot address in option bytes, then just update this option byte to the application address

Best regards

Jocelyn

Markus Schwarzl · ‎2024-09-06

Thank you very much for your response!

Proposal 1 is what I also thought about in the meantime and I'm planning to use for the moment as it has least effort.
Proposal 2 is also great and will solve most situations for debugging with very little effort. Thanks, great!
Proposal 3 is also a nice idea that I'll keep in mind for the future.
Proposal 4 is something I also thought about but as you mentioned this is very risky and something I'd better not do.
Proposal 5 will not work on our current G0 and G4 MCU's. I'll also keep that in mind!

Thank you very much!

Markus

Markus Schwarzl · ‎2024-09-24

Hi!

I need to come back to this topic as I now had to dive into the topic deeper and found another solution that was somehow hidden to me but looks like the perfect solution.

I analyzed the postbuild-scripts and found out that actually the application-elf would be overwritten by a merged elf containing the SBSFU, the application and a header for the application that would already mark the application as "valid"! But if this would be the case I never had opened this thread. So I analyzed why debugging with this elf doesn't work as intended by the ST-SBSFU team and found out that the final elf-merge using the STM32CubeProgrammer with the parameter "-ms" doesn't do its job. The final merged elf file is corrupted somehow (header is at wrong location) and I fell over another thread (https://community.st.com/t5/stm32cubeprogrammer-mcus/how-does-the-utility-stm32-programmer-cli-work-with-the-ms/m-p/723789/highlight/true#M7139) which looks exactly like the same problem. I also tried to flash the merged "bigbinary" and this one works. But this one is generated using the prepareImage-Tool and not the STM32CubeProgrammer. Unfortunatly I couldn't find very much documentation about this special merge command. I would appreciate if this could be solved somehow or maybe an older version of CubeProgrammer works for this job...?

Thanks in advance,

Markus

Jocelyn RICARD · ‎2024-09-25

Hello @Markus Schwarzl ,

this issue was already detected internally 5 years ago but was never fixed probably because not used.

I will create a new internal ticket for that. This could be a good alternative for debugging I agree.

Best regards

Jocelyn

Markus Schwarzl · ‎2024-12-20

Hello @Jocelyn RICARD !

Any update on the internal ticket regarding the issue with the CubeProgrammer?

Best regards,

Markus

Jocelyn RICARD · ‎2024-12-20

Hello @Markus Schwarzl ,

no news.

Now I have seen a new feature with last CubeIDE where you can load a binary.

Didn't have time to check yet but could be a solution if it works

Best regards

Jocelyn