threadx icon indicating copy to clipboard operation
threadx copied to clipboard

ThreadX modules support on Cortex-M33

Open Jasinsky opened this issue 11 months ago • 1 comments

I am running ThreadX from tag v6.4.1_rel with modules-enabled kernel.

When compiled with TX_SINGLE_MODE_SECURE - it hard faults after first enter to the scheduler and PendSV interrupt. PendSV interrupt executes until returning from exception. EXC_RETURN was set to 0xFFFFFFBC and that was causing aforementioned hardfault.

After applying patch below - scheduler runs successfully.

diff --git a/ports_module/cortex_m33/gnu/module_manager/src/tx_thread_schedule.S b/ports_module/cortex_m33/gnu/module_manager/src/tx_thread_schedule.S
index e392380b..ba8c5fea 100644
--- a/ports_module/cortex_m33/gnu/module_manager/src/tx_thread_schedule.S
+++ b/ports_module/cortex_m33/gnu/module_manager/src/tx_thread_schedule.S
@@ -471,6 +471,12 @@ _skip_vfp_restore:
     LDMIA   r12!, {r4-r11}                          // Recover thread's registers
     MSR     PSP, r12                                // Setup the thread's stack pointer
 
+#ifdef TX_SINGLE_MODE_SECURE
+    LDR     r0, =0xFFFFFFFD                         // Exception return to secure
+#else
+    LDR     r0, =0xFFFFFFBC                         // Exception return to non-secure
+#endif
+    MOV     lr, r0
     BX      lr                                      // Return to thread!

It might be that I am not understanding Trustzone secure/non-secure implications.

Following addition was present in MemManage handler e.g. - other interrupts do not have it.

Could someone suggest if this is a scheduler bug for CM33/CM23 and other CMSE architectures or I am configuring my microcontroller wrongly?

Jasinsky avatar Jan 24 '25 11:01 Jasinsky

Thank you for this question, @Jasinsky.

@eclipse-threadx/iot-threadx-committers and @eclipse-threadx/iot-threadx-contributors: can one of you please comment on this issue?

fdesbiens avatar Jan 24 '25 14:01 fdesbiens