vTaskPrioritySet Fails for < 0 prioritys

I believe I have notices a bug in the vTaskPrioritySet( TaskHandle_t xTask, UBaseType_t uxNewPriority )

The “configASSERT( ( uxNewPriority < configMAX_PRIORITIES ) )” fails when priority is set to osPriorityBelowNormal or lower due to “UBaseType_t uxNewPriority” being a "unsigned long.

My code was generated by STM CUBE for STM32L071 Cortex M0 microcontroller.

Factual code:

tasks.c:

void vTaskPrioritySet( TaskHandle_t xTask, UBaseType_t uxNewPriority )
{
TCB_t *pxTCB;
UBaseType_t uxCurrentBasePriority, uxPriorityUsedOnEntry;
BaseType_t xYieldRequired = pdFALSE;

		configASSERT( ( uxNewPriority < configMAX_PRIORITIES ) );

freertosconfig.h:

#define configASSERT( x ) if ((x) == 0) {taskDISABLE_INTERRUPTS(); for( ;; );}

portmacro.h:

typedef unsigned long UBaseType_t;

cmsis_os.h:

typedef enum {
osPriorityIdle = -3, ///< priority: idle (lowest)
osPriorityLow = -2, ///< priority: low
osPriorityBelowNormal = -1, ///< priority: below normal
osPriorityNormal = 0, ///< priority: normal (default)
osPriorityAboveNormal = +1, ///< priority: above normal
osPriorityHigh = +2, ///< priority: high
osPriorityRealtime = +3, ///< priority: realtime (highest)
osPriorityError = 0x84 ///< system cannot determine priority or thread has illegal priority
} osPriority;

The values osPriority... do not belong to the FreeRTOS distribution, do they?

Within FreeRTOS, the priority is expressed as an unsigned number, between tskIDLE_PRIORITY and configMAX_PRIORITIES-1.

Isn’t there some mapping between the two ranges?

vTaskPrioritySet does not use the CMSIS priority levels defined in the enum osPriority, but numbers in the range of 0 (lowest) to (configMAX_PRIORITIES-1). There will be a CMSIS layer function that maps the CMSIS priorities to the native FreeRTOS priorities, or you can just use the number of the actual FreeRTOS priority you want.

In the cmsis_os.c it calls xTaskCreate with one of the parameters being “makeFreeRtosPriority(thread_def->tpriority)”

As I can’t call “makeFreeRtosPriority” I just used “priority - osPriorityIdle”

It’s clearly not a bug but just a complication, missguidance.

Factual code:

cmsis_os.c:

/* Convert from CMSIS type osPriority to FreeRTOS priority number */
static unsigned portBASE_TYPE makeFreeRtosPriority (osPriority priority)
{
unsigned portBASE_TYPE fpriority = tskIDLE_PRIORITY;

  if (priority != osPriorityError) {
    fpriority += (priority - osPriorityIdle);
  }
  
  return fpriority;
}

...
  if (xTaskCreate((TaskFunction_t)thread_def->pthread,(const portCHAR *)thread_def->name,
                   thread_def->stacksize, argument, makeFreeRtosPriority(thread_def->tpriority),
                   &handle) != pdPASS)  {
    return NULL;
  }     

cmsis_oc.c is third party code so it is difficult to support directly. Can you just use the native FreeRTOS API?

cmsis_os.c was generated by STM CUBE as a package. I believe that the whole bundle - the freertos and HAL libraries are well written. There are things I would have done differentley but for the sake of fast developement, I have no intention to poke around the generated code, if not needed.
I only want to understand the workings behind it so I know what options I have and to be carefull of these little traps in the future projects.

Maby my post was a bit premature, but I am glad to see that the forum is very responsive!

Thank you.