Azure RTOS Integration in B-U585-IOT2A Bootloader Environment

[Nitin]

Hello ST, I am trying to integrate ThreadX into TFM_Appli-NonSecure project. Mostly I am able to integrate it and execute but to make a thread run, I have to comment _tx_initialize_low_level(); API in _tx_initialize_kernel_enter() function.

This all work smoothly until I try thread context switching. My initial understanding assumption says pendsv_hander is not getting called.

Could I get some more insight to resolve this issue as there is no direct example available for this.

[liaifat85]

Since you suspect that the PendSV handler is not getting called, verify the configuration related to PendSV in your setup. Make sure that the vector table is correctly set up to point to the correct PendSV handler function.

[Nitin]

To be precise, after this call MCU is getting reset in loop

/* Set PendSV to invoke ThreadX scheduler. */

*((volatile ULONG *) 0xE000ED04) = ((ULONG) 0x10000000);

[Nitin]

Thanks for replying, everything seems correct to me. One of the main reason behind this can be some TF-M violation.

[Guillaume K · Accepted solution]

Hello

Did you look at X-CUBE-AZURE - Microsoft Azure software expansion for STM32Cube - STMicroelectronics ?

It has an example of TFM NS application with ThreadX.

it's in Projects\B-U585I-IOT02A\Applications\TFM_Azure_IoT

normally you shouldn't comment _tx_initialize_low_level().

ThreadX requires to use the SysTick interrupt for its own tick (10 ms). it is done in _tx_initialize_low_level.

There is conflict with STM32 HAL that uses Systick for its own tick (1 ms).

Solution is to use additional timer TIM6 instead of SysTick for HAL tick.

See examples with ThreadX (especially Netxduo examples) in STM32 Cube U5.

Also because it is a TrustZone non-secure app there are some ThreadX sources and #define that must be added in the project.

tx_thread_secure_stack_allocate/_free.c, txe_thread_secure_stack_allocate/_free.c

tx_thread_secure_stack_initialise/_build.s

add define TX_SINGLE_MODE_NON_SECURE=1 at project level for C compiler

add define TX_SINGLE_MODE_NON_SECURE for assembler files

see Chapter 2 - Installing ThreadX support for ARMv8-M | Microsoft Learn

[Jocelyn RICARD]

Hello Nitin,

on top of Guillaume's feedback, one other point to check is relative to interrupt vector pointer.

In _tx_initialize_low_level you reference g_pfnVectors (at lines 527 and 538)

    /* Setup Vector Table Offset Register.  */
    MOV     r0, #0xE000E000                         // Build address of NVIC registers
    LDR     r1, =g_pfnVectors                       // Pickup address of vector table
    STR     r1, [r0, #0xD08]                        // Set vector table address

    /* Enable the cycle count register.  */
    LDR     r0, =0xE0001000                         // Build address of DWT register
    LDR     r1, [r0]                                // Pickup the current value
    ORR     r1, r1, #1                              // Set the CYCCNTENA bit
    STR     r1, [r0]                                // Enable the cycle count register

    /* Set system stack pointer from vector value.  */
    LDR     r0, =_tx_thread_system_stack_ptr        // Build address of system stack pointer
    LDR     r1, =g_pfnVectors                       // Pickup address of vector table
    LDR     r1, [r1]                                // Pickup reset stack pointer
    STR     r1, [r0]                                // Save system stack pointer

But in actual interrupt vectors definition in startup_stm32u5xx.c of non secure application example, you have 

extern const pFunc __VECTOR_TABLE[];
       const pFunc __VECTOR_TABLE[] __VECTOR_TABLE_ATTRIBUTE = {
  (pFunc)(&__INITIAL_SP),           /*      Initial Stack Pointer */
  Reset_Handler,                    /*      Reset Handler */
  NMI_Handler,                      /* -14: NMI Handler */

So you probably need to align the naming.

I didn't have time to double check but worth trying because your issue seems related to this

Best regards

Jocelyn

[TDJ]

@Nitin Why do not you use the original Arm TF-M solution?
The reason I ask is because I just spend entire week testing TFM and SBSFU apps, going thorough all the docs to make sense out of it and then I learned that TFM has been recently removed from GitHub and, I assume, will not be supported anymore. Probably the same is true for SBSFU. See issue #37 & issue #38.

TF-M solution 2.0 is a state-of-the-art solution, contains preconfigured profiles for the following ST MPUs/boards:
b_u585i_iot02a
nucleo_l552ze_q
stm32h573i_dk
stm32l562e_dk
It is actively maintained (new commits everyday), is highly configurable, has own community supporting it, current roadmap and well documented releases  - which is not to be said about ST TFM app, probably based on relatively old TF-M 1.3. There is just one thing, as I found out, to understand how TF-M is supposed to be used one needs to study MCUboot design and PSA Certified Firmware Update API documents first (TF-M is really MCUBoot extension).

In my view, it is actually good that ST stopped supporting TFM because it clearly had no commitment, capacity and motivation to do it well enough. This effort could be much better spend on supporting the original Arm TF-M and own HAL. Maturity-wise ST is still where Microsoft used to be during Steve Ballmer era, still dreaming of total market domination, trying to provide own software everywhere (e.g. own Internet Explorer renderer) instead of focusing on HAL quality while contributing and collaborating anywhere else, where it would make much more sense.
I would happily pay 50% more for ST MCUs and would not even look at alternatives if they came with high quality HAL and examples, but currently this is not an option.

Just my 3 cents.

[Pavel A.]

@TDJ ST does support trustedfirmware.org, they are even listed as a Platinum member.  https://www.trustedfirmware.org/join/

[TDJ]

@Pavel A. Correct, there is hope, on the list of TF-M maintainers there is one ST employee.

[Nitin]

Thanks Guillaume for the detailed reply.

Things are much clear now. But I still have some problem to be resolved(may be last one). Actually I have some issue with below statement from the link provided.

"The file tx_thread_secure_stack.c must be added to the secure application."

It's not clear to me actually and I am getting undefined reference for all the functions defined in this file.

(.text+0x60): undefined reference to `_tx_thread_secure_stack_context_save'
(.text+0x90): undefined reference to `_tx_thread_secure_stack_context_restore'
(.text+0xfe): undefined reference to `_tx_thread_secure_mode_stack_allocate'
(.text+0x110): undefined reference to `_tx_thread_secure_mode_stack_free'
(.text+0x120): undefined reference to `_tx_thread_secure_mode_stack_initialize'

Moreover Projects\B-U585I-IOT02A\Applications\TFM_Azure_IoT is not directly compiling. So not able to take much help from it.