2024-05-22 11:04 PM - edited 2024-05-22 11:16 PM
Hello,
I am developing synchronization libraries on top of ThreadX for an STM32 project. My libraries work perfectly when used on ONLY either the M4 or M7 core while the other core is idling. However, when I attempt to run ThreadX on both cores in AMP fashion with separate kernels, the M4 core encounters a hard fault.
After investigating, I found that the issue originates in the M4 core's signal handler due to a stack overflow in the System Timer Thread. The strange part is that the M4 core is not creating any threads and is running only the skeleton code generated by CubeMX (obviously, the error remains even when application threads are created). Notably, if I run only the initialization (skeleton) on the M7 core without creating any application threads, the stack overflow issue does not occur on the M4 core.
By default, all stacks are allocated in AXISRAM. So, to ensure that application threads created on the M7 core are not interfering with the M4's System Timer Thread stack, I changed the M7 thread stack allocation to SRAM2. Despite this, I still encounter the same issue.
I am at a loss as to what could be causing this problem. Below are some images showing the hard fault and thread stacks on both the M7 and M4 cores.
Any insights or suggestions would be greatly appreciated.
Images showing no stack overflow when additional threads on M7 are not created: