Skip to main content
Graduate
September 22, 2025
Solved

Priority inheritance on mutexes not working any more in freeRTOS?

  • September 22, 2025
  • 2 replies
  • 535 views

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

    This topic has been closed for replies.
    Best answer by Khaled_DHIF

    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

     

    2 replies

    Technical Moderator
    September 24, 2025

    Hi @herbert 

    Would you share a minimum example to reproduce the issue?

    herbertAuthor
    Graduate
    September 24, 2025

    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

    ST Employee
    September 26, 2025

    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

     

    herbertAuthor
    Graduate
    September 26, 2025

    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