2024-01-12 05:10 AM
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.
Solved! Go to Solution.
2024-01-17 11:06 PM
Thanks Jocelyn, you got it correctly. g_pfnVectors was one of the issue and it got resolved after replacing with __Vectors.
2024-01-18 12:36 AM
Hello Nitin
regarding the missing functions you mention (_tx_thread_secure_stack_context_save, etc), did you define TX_SINGLE_MODE_NON_SECURE for C compiler AND also for the assembler ?
what IDE/compiler are you using ?
In fact, some of the tx_thread_secure_* files are not really used in case of non-secure application. I guess Microsoft suggest to put everything in the project in case you switch it to secure side.
- What do you mean by "Projects\B-U585I-IOT02A\Applications\TFM_Azure_IoT is not directly compiling. " ?
In this package, several other projects must be compiled before the non secure application (bootloader, TFM secure application, etc).
If you use IAR EWARM , you must run the batch build (F8) that will compile the project in correct order.
If you use STM32CubeIDE, in TFM_Appli project normally there are references to other projects that will make them compile before. You have to import in your workspace all the STM32CubeIDE projects under Projects\B-U585I-IOT02A\Applications\TFM_Azure_IoT .
If you are using STM32CubeIDE version 1.14.0 , try to switch to 1.14.1 released recently. Version 1.14.1 corrects problems when running shell commands from STM32CubeIDE.
2024-01-18 10:00 AM - edited 2024-01-18 10:15 AM
Hi Guillaume, I was doing one silly mistake. Actually I didn't included TX_SINGLE_MODE_NON_SECURE for the assembler.
Now,
tx_thread_secure_stack_allocate/_free.c, txe_thread_secure_stack_allocate/_free.c, tx_thread_secure_stack_initialise/_build.s included(as I am able to compile my code.
I followed all these steps but still my application is not moving past
*((volatile ULONG *) 0xE000ED04) = ((ULONG) 0x10000000);
And device is resetting continously. Is there anything I am still missing!!!
Only doubt I have is, “The file tx_thread_secure_stack.c must be added to the secure application.” I have not added this file into secure area.
2024-01-19 09:52 AM
Hello ST, please guide me to resolve this issue. Is PendSV priority has to be changed to trigger the interrupt?
2024-01-22 12:20 AM
Not sure why it doesn't work. I don't have your full project. It could be anything.
Did you compare with what is done in X-Cube-Azure package ?
Don't touch PendSV priority. it should be 15 (lowest).
TIM6 should be higher priority than PendSV (so for example 14).
2024-01-22 07:35 AM
Hi Guillaume, I have commented here in this thread. This thread is most relevant to my current blockage. If you could look into this.
I don't this their much work done on STM32U585 series, specially on TFM + BL setup. We are expecting active support from ST on this.
2024-01-22 09:02 AM
The thread you mention talks about customisation of interrupt vectors table address on STM32L4.
It is different on STM32U5 in TFM environment.
Do you have in your code the function SystemInit() in system_stm32u5xx.c? could you compare your code with reference TFM implementation in Projects/B-U585I-IOT02A/Applications/TFM/TFM_Appli/NonSecure/Core/Src/system_stm32u5xx.c, function SystemInit():
There should be only these lines:
void SystemInit(void)
{
/* FPU settings ------------------------------------------------------------*/
#if (__FPU_PRESENT == 1) && (__FPU_USED == 1)
SCB->CPACR |= ((3UL << 20U)|(3UL << 22U)); /* set CP10 and CP11 Full Access */
#endif
}
when comparing to "standard" system_stm32u5xx.c some code is removed. the SCB->VTOR register is not modified directly in this file. also some clock settings are not changed. If the lines modifying SCB->VTOR are present then it could explain the problem.
2024-03-01 04:45 AM - edited 2024-03-02 11:16 AM
Good to know about X-Cube-Azure.