Dear FreeRTOS, I did a mistake and configured FreeRTOS wrong. I configured configMAX_PRIORITIES too small, which caused unexpected task preemptions since xTaskCreate() does silently set back the passed priority to max configured. Unfortunately no configASSERT() fired. We looked at the code and found a missing configASSERT( ( uxNewPriority < configMAX_PRIORITIES ) ) In prvInitialiseNewTask() which is called by xTaskCreate(). Interesting is, that in vTaskPrioritySet() does have that configASSERT(), but I did not use that function and FreeRTOS did not complain about my mistake. That’s a pity. Is there any reason why not having the configASSERT( ( uxNewPriority < configMAX_PRIORITIES ) ) checked in xTaskCreate(), too? Using FreeRTOS 10.0.0 regards spachner

I think the only reason is the documented behaviour is that the priority is capped to configMAX_PRIORITIES.

Hi, thanks for the quick respoonse, I highly appreciate this. Yes, you are right, the priority capping is mentioned in der reference manual, unfortinuatly not in the web site: https://www.freertos.org/a00125.html Good to know, that the website is not as complete as the manual. However despite the capping is also mentioned in the manual for vTaskPrioritySet() there is that assertion

    configASSERT( ( uxNewPriority < configMAX_PRIORITIES ) );

I recommend to add that same assert to xTaskCreate(), too. regards spachner

Hi, thanks for the quick respoonse, I highly appreciate this. Yes, you are right, the priority capping is mentioned in der reference manual, unfortinuatly not in the web site: https://www.freertos.org/a00125.html Good to know, that the website is not as complete as the manual. However despite the capping is also mentioned in the manual for vTaskPrioritySet() there is that assertion

    configASSERT( ( uxNewPriority < configMAX_PRIORITIES ) );

I recommend to add that same assert to xTaskCreate(), too. regards spachner