0

I would like to install threadX on a STM32L476VG. I am quite new to RTOS programming.

As I set up some simple applications I run into a HardFault whenever I called the tx_thread_resume function within an interrupt routine (lets say the USART3 interrupt).

I figured that this is when SVC 0 is called at the end of the tx_thread_resume function. The problem can be solved, when the interrupt priority of the interrupt in which routine the tx_thread_resume call is made is set to 0xF (USART1 interrupt in this case).

I suspect this is because threadX sets the interrupt priority of the SVC exception to 0xF and a SVC Call with lower priority within the not terminated interrupt routine of the USART1 is causing the hardfault. But I don't find any evidence in the documentation, not in threadX documentation and not in the STM32L4 documentation about the SVC Call.

Is my suspicion about the SVC call being illigal causing the hardfault correct or lies the reason for the hardfault elsewhere?

Thank you for your time.

NoiseEngineer
  • 3
  • 1

1 Answers1

1

We don't actually call SVC in the normal ThreadX Cortex-M ports (only in the Modules ports). We do set the PENDSV bit in ICSR. This is done in tx_thread_system_return.s which is called at the end of tx_thread_system_resume.c.

By default, ThreadX sets PendSV to the lowest priority (0xFF) in tx_initialize_low_level.s, which should not be changed. All of your interrupts should be higher priority than this. What is intended to happen is that once your (e.g. USART1) ISR completes, the Cortex-M hardware detects the pending PendSV exception and does tail-chaining, immediately processing the PendSV interrupt once the USART1 interrupt completes.

I do not suspect your hardfault is caused by the PendSV interrupt. Can you step through the tx_thread_system_resume.c and tx_thread_system_return.s functions and find exactly where the hardfault is hit?

Also, what is the size of the thread stack that has been interrupted?

ScottAzureRTOS
  • 166
  • 5
  • Thank you for the answer. This actually helps me a lot. In my application, there is an SVC Call being made within the tx_thread_system_return.s. So after your answer, it is clear to me, that this is not an issue of ThreadX, but more an issue of understanding the consequences of interrupt priorities in general: I cannot make a low prio interrupt within an high prio interrupt as the low prio cannot resolved within the high prio and therefore the high prio cannot be completed without resolving the low prio. I hope this is indeed the issue, but it sounds logical for me. – NoiseEngineer Oct 20 '22 at 09:12
  • can you link me to the tx_thread_system_return.s file that is calling SVC? – ScottAzureRTOS Oct 21 '22 at 16:09