How to configure interrupt priorities in a ThreadX project

[Hareesh_S]

Hello,

From my understanding in FreeRTOS, there is a defined highest priority one should set for interrupts whose ISRs may call RTOS APIs (configMAX_SYSCALL_INTERRUPT_PRIORITY).
For the same reasons, I would expect ThreadX to have a similar limitation, and to that extent I have found other ST forums posts suggesting one should set lower priorities for any interrupts whose ISRs may call RTOS APIs, but I can't find any documentation that explicitly states what the highest safe/allowable priority is, similar to FreeRTOS.

How do I know what's the highest interrupt priority I can safely set in such cases? Is there any documentation from ThreadX that I'm missing, because I can't seem to find any mention of this.

For context, I am using a U5 series MCU and I want to call queue related APIs in my CAN Rx callback.

[AScha.3]

Hi,

That's not so difficult:

If you want the rtos working, leave it it's high priorities.

Your tasks then at lower priorities as you like.

->

[Pavel A.]

in ThreadX you can customize macros TX_DISABLE and TX_RESTORE to behave like in FreeRTOS (use BASEPRI), but it seems that CubeMX GUI does not have this option.

[Hareesh_S]

@AScha.3 
Yeah it's pretty straightforward in practice, but I just want to know (for educational purposes) what the actual hard limit is. I would assume its whatever the lowest priority is between pendSV, SysTick and SVCall?

@Pavel A. Interesting, but yeah, I was just assuming that ThreadX themselves would have a hard limit, or mention somewhere what that recommended limit is

[Haithem Rahmani · Accepted solution]

Hi @Hareesh_S  @Pavel A. 

Actually the BASEPRI support is available in ThreadX and configurable in STM32CubeMX.

regards
haithem.

[Hareesh_S]

Hello @Haithem Rahmani 

Okay so essentially there is no fixed absolute limit and it is up to developer's discretion what the BASEPRI value is?
I don't fully understand the intended benefit of it in that case, but this answers my initial question regardless.
Much thanks!