Thread suspension generates a Hard_Fault on STM32U5 with ThreadX

[Bastien LS]

I am working on NUCLEO-U575ZI-Q. The code is generated with STM32CubeMX (using STM32CubeIDE) and the application uses ThreadX, which was added to the project using CubeMX.

When a thread call any function that would lead to a suspension of the thread, the function _get_ipsr() (file Middlewares\ST\threadx\ports\cortex_m33\gnu\inc\tx_port.h) is called and it directly triggers a Hard_Fault.

The error would trigger 100% of the time with some source code, and never with some other source code.

I am having this error for a while. I thought I found the solution before, but I was wrong and it was all just luck.

According to this link:

How to debug a HardFault on an ARM Cortex-M MCU | Interrupt (memfault.com)

There is a usage fault with the flag "UNALIGNED" raised. However please note that last time I had trouble with _get_ipsr(), the only flag set to 1 was in the "reserved" field of the usage fault register.

I still working on the issue but I am having trouble finding a solution. Do you have an idea on what could go wrong or how to solve this issue?

[Haithem Rahmani]

Hi @Bastien LS​,

Are you using the Trust Zone feature or not?

Did you try the ThreadX application provided within the STM32Cube_FW U5, does the issue appear with any of them?

regards

Haithem.

[Bastien LS]

Hi @Haithem Rahmani​ 

I am not using the Trust Zone feature.

I just tried 3 example applications "TX_Thread_Creation", "TX_Thread_MsgQueue", "TX_Thread_Sync" and all of them worked well.

[Haithem Rahmani]

@Bastien LS​ 

then could you check what is the difference between your project and the working ones?

regards

Haithem.

[Bastien LS · Accepted solution]

So I simplified the threads again and again to make them as close as possible as the examples, until I realized :

Although the execution of the function _get_ipsr() generates a crash, it is NOT responsible for the crash ; I was being very naive with the debugger.

The crash actually happens in an other thread, _get_ipsr() is just the last function called from a thread yielding, and leads to an other thread being run.

I found the source of the crash, could understand and solve the issue.

Thank you for the help.

Regards

[TDJ]

@Bastien LS Did you find the solution? I may be having exactly the same problem on STM32U5A9, no trust - hard faults with UFSR=16 (unaligned), HFSR=0x400000000 (bit 30 set - forced). I cannot find any clear pattern to that. It is not a large code, plenty of SRAM, crash happens inside tx_* functions, e.g. tx_mutex_put(). When I step through it usually does not crash. I start to pull my hair out. MS has a newer version than than the one distributed by CubeMX. It seems it has some fixes.

[TDJ]

I just found the problem. TX_APP_STACK_SIZE was simply too small.