cancel
Showing results for 
Search instead for 
Did you mean: 

Priority inheritance on mutexes not working any more in freeRTOS?

herbert
Associate III

Hello,

I have been using the example for priority inheritance from the FreeRTOS on STM32CMSIS_OS APIv2.0 slide set for some time noe as an example to show to my students how priority inheritance ist working. But since upgrading to STM32CubeIDE v1.19.0 it seems this is not working any more. The is no difference now between using mutexes or semaphores. Has anybody made the sam experience so far?

regards
Herbert

1 ACCEPTED SOLUTION

Accepted Solutions

Hello @herbert ,

I have verified that priority inheritance still occurs with your code when using STM32CubeIDE v1.19.0.

You can also observe this behavior directly in the debugger by following these steps:

  • Open the view via Window → Show View → FreeRTOS → FreeRTOS Task List.
  • After lowering the priority of myTask02, you will see both the base and actual priorities displayed.
  • The actual priority being higher than the base priority clearly indicates that priority inheritance is taking place as illustrated in this screenshot below:

Free.png

In contrast, when using semaphores (which do not support priority inheritance), you may notice that the scheduler continues running other higher priority tasks (such as myTask04), while myTask02 is starved and unable to run to release the semaphore, thereby blocking myTask03

To assist you further, could you please share more context about your project setup and code, including:

  • Exact FreeRTOS and CMSIS-RTOS versions,
  • Relevant parts of your FreeRTOSConfig.h,
  • Any modifications made after upgrading STM32CubeIDE.

This will help us pinpoint any configuration or environment factors affecting your experience.

Best regards,
DHIF Khaled

 

Please mark my answer as best by clicking on the “Accept as solution" button if it fully answered your question. This will help other users find this solution faster.​

View solution in original post

4 REPLIES 4
FBL
ST Employee

Hi @herbert 

Would you share a minimum example to reproduce the issue?

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.


herbert
Associate III

Hi,

basically this is the example code from the "FreeRTOS on STM32 CMSIS_OS API v2.0 T.O.M.A.S – Technically Oriented Microcontroller Application Services" slide set, chapter on "mutex lab (pages 342ff in Adobe). I have just modified it a little bit to easily switch between mutex and semaphore code. It was executed on a STM32F411DISCO board and executed just as described in the document up to STM32CubeIDE V1.18.1. Since upgrading to V1.19.0 the code shows the same behavior for mutexes as for semaphores. It looks to me as if priority inheritance is not working any more.

regards
Herbert

Hello @herbert ,

I have verified that priority inheritance still occurs with your code when using STM32CubeIDE v1.19.0.

You can also observe this behavior directly in the debugger by following these steps:

  • Open the view via Window → Show View → FreeRTOS → FreeRTOS Task List.
  • After lowering the priority of myTask02, you will see both the base and actual priorities displayed.
  • The actual priority being higher than the base priority clearly indicates that priority inheritance is taking place as illustrated in this screenshot below:

Free.png

In contrast, when using semaphores (which do not support priority inheritance), you may notice that the scheduler continues running other higher priority tasks (such as myTask04), while myTask02 is starved and unable to run to release the semaphore, thereby blocking myTask03

To assist you further, could you please share more context about your project setup and code, including:

  • Exact FreeRTOS and CMSIS-RTOS versions,
  • Relevant parts of your FreeRTOSConfig.h,
  • Any modifications made after upgrading STM32CubeIDE.

This will help us pinpoint any configuration or environment factors affecting your experience.

Best regards,
DHIF Khaled

 

Please mark my answer as best by clicking on the “Accept as solution" button if it fully answered your question. This will help other users find this solution faster.​
herbert
Associate III

Hello @Khaled_DHIF ,

thank you very much for your tips. With you help I found out that the tasks are indeed working as intended, it just happened that the LED which was used to indicate the fact that the task is running does have a problem and seems to be broken, or at least running erratically. With a different board everything works fine. 

I apologize for not thinking about this possibility earlier, it might have saved both of us some time.

Anyhow, I thank you for your assistance which once more did show me that ST and its people are great! 

Thanks again
Herbert