0

I have a project with an STM32F446, with RTX, 3 threads (main + 2 declared by me) + of course the idle one. The main thread enters wait state after starting the two threads so i have just two threads running. The RTX has round robin disabled. What the application does is talk to a a Bluetooth module over SPI.

My problem is that sometimes, during the SPI transfer (initiated by one thread and done in the other)the MCU crashes into the UsageFault_Handler and one of the threads (not always the same) is shown to overflow. Now I have read about how to debug the hardfaults and what nots but the problem is that all of the methods rely on MSP/PSP addresses and for me the PSP is 0x00000020. Anyone ever confronted with something similar? Any ideas on what might be wrong?

LE: I have since learned that the code works with FreeRTOS and not RTX. The code uses critical sections. I have tried using the same implementation for the critical section for RTX as for FreeRTOS(BASEPRI) but I often end up in UsageFault. I know that RTX uses extensively the SVC in the code.

Could it be that the Critical sections should be implemented differently ? Do you know of any other differences between FreeRTOS and RTX that could cause problems?

Later Edit(Solved): it turns out that the problem was related to the priority assigned to the SysTick. It was first set up to the lowest priority as it should but, a piece of code, somewhere was setting the SysTick to a very high priority.

Thank you!

a85ja
  • 3
  • 3

1 Answers1

0

When a function returns its stack pointer is restored, if the stack were corrupted, an invalid value may be restored, so the value in SP is not particularly useful or informative.

Of course all other registers including the program counter are likely to be corrupted too. The UsageFault occurs on undefined instructions, unaligned memory access - either of which are likely if a return is executed with a corrupted stack since the return could end up anywhere. You may even find that changing the code leads to different fault types. Without sight of the code, it is not possible to determine the cause, but likely issues are local-data buffer overruns or simply insufficient stack space allocated.

The easiest way perhaps to diagnose this fault is to use debug hardware with trace capability, though these are more expensive that a simpler JTAG or SWI debugger.

Clifford
  • 88,407
  • 13
  • 85
  • 165
  • Thank you for your answer. One thing that i forgot to mention is that the code worked perfectly without an OS. After I included the RTX, the error keeps appearing every now and then, not at the same time. – a85ja Oct 23 '17 at 11:39
  • Well in an RTOS each task has an independent stack of user defined size. The ARM linker has options to generate starch usage analysis. Use it to check the stack requirement for your task entry points, and `main()`. The main stack will continue to be used for interrupts. – Clifford Oct 23 '17 at 12:30