Integrating TouchGFX and SBSFU

[JoeMck]

I am trying to integrate a very simple TouchGFX Application into the SBSFU (I only really need SB right now) application, on STM32U5A9J-DK

I've switched out the Nonsecure application for mine, I've modified flash_layout to do primary only, no external loader, 1 image. I modified the template loader script to have a Framebuffer section that spans SRAM3 (minus the secure section) and SRAM5. I'm using the startup_stm32...c that the original nonsecure application uses.

Right now. It builds and boots, and shows "Jumping to first Image Slot" and just sits. I think it's getting into the Appli_Secure, because the Users LEDs on my board are lighting up.

I found some verbiage elsewhere that indicates that I likely need to unsecure the IOs and SRAMs that the new NonSecure application uses, but when I start doing that, things go haywire.

For example, I've got my project setup so that I can switch back to using the original demo Appli_NonSecure with my modifed flash_layout.h and linker script, and so I switch back to that, and the demo appears functional. I get the menu with the ability to toggle the secure LED. Great. But then I go into secure/src/main.c and execute code that unsecures my NS_DATA_XXXX that is now in SRAM3 and SRAM5, and the demo app stops functioning, and I get similar behavior to what I indicate above. I separately tried to go into partition_stm32u5a9xx.h and set SAU_REGION4 to be my new NS_DATA_START3 section, and I see the identical behavior as above.

And so, I'm at a place where the stuff I think I may need to be doing for my new Appli_NonSecure is breaking the original Appli_NonSecure. I don't yet understand why unsecuring memory that AFAICT is unused in either the Appli_Secure or the original Appli_NonSecure is breaking things.

Are there any resources that anyone could point me to that might clearly be corelated to the issues or challenges I'm seeing? I feel like I've read all the usual suspects (UM2851, AN4992, et cetera), and these all have alot of words about what can and can't be done, but it feels like very little about how to actually do these things.

[Jocelyn RICARD]

Hello @JoeMck ,

I don't know any good guide to start using TrustZone from scratch. There are lots of resources on the web and youtube but nothing that brings you step by step unfortunately.

One important point is to be able to use debugger. In my view this is not possible to do anything in embedded software using led or trace. You must use debugger to see and understand what happens.

The point here is that whenever something goes wrong you have very good change to get a fault.

The first one is the secure fault : this directly points the SAU configuration, easy.

The second one can be the memory fault: in such case this is the MPU configuration that needs to be adapted. This can be tricky

Then you get other fault, usually when RAMs are not properly setup in GTZC. In such case you can get a GTZC interrupt but this is usually not enabled. As you will read RAM as 0 you often end up in a hardfault.

There are many potential issue when working with TrustZone.

Here you just need a secureboot. And SBSFU example requires the activation of TrustZone.

The original reason for that is that SecureBoot code protection mechanism (HDP) is only available when TrustZone is enabled.

This is still possible to have a secure boot without enabling TrustZone. This will be possibly less robust but you will not need to deal with TrustZone.

There are possibly third party implementations of secure boot that don't use TrustZone but probably not free.

To address this I'm working on providing a secure boot solution not requiring TrustZone on ST hotspot but this requires some time as you may guess.

Best regards

Jocelyn

[JoeMck]

Hi Jocelyn, Thank you for your response. Yeah. I've just figured out how to add all 3 elfs to the debug configuration to be able to debug past the jumps. I think I've made some progress. Right now, I'm getting a Hard Fault in:

(my Appli_NonSecure main.c)

        (stm32u5xx_hal.c) HAL_Init()

         (stm32u5xx_hal_timebase_tim.c) HAL_InitTick()

         (stm32u5xx_hal_cortex.c) HAL_NVIC_EnableIRQ()

The fault analyzer tab said FORCED and VECTBL. So I'm currently looking into the ISR vector.