FreeRTOS with SBSFU is not working

[PYada.1]

I am using the STM32L562E-DK development kit. I have taken reference to NUCLEO-L552ZE-Q and ported it for STM32L562E-DK. Also added External OSPI flash. without FreeRTOS it is working fine.

I have added FreeRTOS in the nonsecure application. For that, I have made the following changes

1) Adopt Middleware folder as provided in "FreeRTOS_ThreadCreation" example of STM32L562E-DK

2) Adopt stm32l5xx_hal_timebase_tim.c

3) Remove SysTick_Handler() definition in stm32l5xx_it.c file.

4) Add void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim) API in main

5) Add osKernelInitialize(); and osKernelStart(); in main().

The same changes are working for the GPIO_IOToggle example. I am able to toggle GPIO in the thread. But in the case of the SBSFU Application is not working. Is there any specific change is required in bootloader or application?

@Frantz LEFRERE​ , @Jocelyn RICARD​  Can you please guide me regarding it?

[alister]

>Is there any specific configuration required to use a timer in the nonsecure application?

You have boot code. You have an app. The app and possibly the boot code can write an app image into an install slot ready to be installed. Next reset, if it's there, the boot code will authenticate, optionally decrypt, install it to an active slot and execute it. If it isn't there, the boot code will authenticate the app in the active slot and if it looks ok it will execute it.

Nothing's perfectly secure. There are degrees of secure. But adding the nonsecure adjective to the app is only confusing things.

I'm confused.

I'm unsure if you're talking about the app or perhaps the part of the boot code (SBSFU) that ST name the SFU.

I'm wondering if nonsecure is a mistake and you're using MPU for protection and you really mean unprivileged.

Let's keep the language simple.

It doesn't matter if the timer is in your boot code or in your app code.

Disable all your SBU protections.

Get these parts working separately:

1. Timer
2. FreeRTOS
3. Application
4. Application image
5. SBSFU without protections installing image
6. SBSFU without protections executing an already installed image
7. SBSFU with protections

Suggest use different secret keys for Debug and Release builds for whatever encryption you're using. I.e. a Debug boot code can install/execute a Debug app and a Release boot code can install/execute a Release app. Pass your build config name to your app's post-build script so it knows which key to use.

To get your timer going, there are many references: Community, Google, the reference manual, AN4776, examples (allegedly).

[Jocelyn RICARD]

Hello,

to @alister​ 

The issue described by @PYada.1​ concerns STM32L5 with TrustZone activated.

The SBSFU in this case is not the same implementation as the X-CUBE-SBSFU but using MCUBoot.

As you have TZ, you get 2 application. One located in Trusted or secure part and second one located in non trusted or non secure part.

to @PYada.1​ 

Each interrupt can be set secure or non secure.

You should call NVIC_SetTargetState(TIM6_IRQn) to allocate timer 6 interrupt to non secure.

Best regards

Jocelyn

[PYada.1]

@Jocelyn RICARD​,

Thank you I was exactly looking for this answer. After calling NVIC_SetTargetState(TIM6_IRQn) API in the secure application's main(), I am getting timer interrupt. Now I am able to use TIM6 as a systick. os_delay() and HAL_Delay() both are working fine.

But if I tried to call SECURE_GPIO_Toggle() which toggle GPIO which is secure, although API is defined with "secureportNON_SECURE_CALLABLE" attribute in the secure application(In work around solution it was working fine as expected), I am getting SecureFault_Callback, Is there anything I am missing for FreeRTOS regarding the trust zone?

[PYada.1]

@Jocelyn RICARD​ , @Frantz LEFRERE​ 

Do you have any input or suggestions regarding it?

[Jocelyn RICARD]

Hello @PYada.1​ 

You need to make sure that your mapping makes non secure callable area in line with the SAU configuration.

So, your non secure callable API should be linked to this specific address.

You can check using debugger, going in step by step in assembly and locate exact instruction that leads to this secure fault.

This should give you the root cause of your issue

Best regards

Jocelyn