CMSIS_OS2 proper priorities when overlaid on FreeRTOS

[Harvey White]

Transitioning a working FreeRTOS project over to CMSIS_os2.  Got most of the bits and pieces to compile.  It’s not working (surprise).

At the  simplest level, the patch of code that turns on an LED, then calls osDelay does not delay.  

investigating the problem using vTaskDelayUntil (and bypassing the CMSIS_OS2 wrapper for this one call to eliminate the possibility that the error is in how the cmsis_os2 routine is somehow wrong), the problem is that the xTickCount never increments.  (HAL TICK works and increments).

This triggers an error routine because the new timetowake is computed as less that the existing time.  

Therefore, no delays.

Going through error reports suggests that the TickCount interrupt never triggers.  This seems to be true.

My thought is that the default priorities that are assigned are wrong, so in cmsis, which assigns interrupt priorities, is getting it wrong.  The main task is at priority 24 (PriorityNormal).   Tasks created for LED blinking are set at priority 26 and use osDelay (which calls vTaskDelay).

Any thoughts (code works with not using cmsis threads, so I’m blaming setups.

 

 

[Bob S]

There is a lot of missing info here, so here are some general ideas:

RTOS task/thread priorities are NOT the same as hardware interrupt priorities.  There is no way for thread priorities to prevent the system tick timer (hardware) interrupt from getting serviced.

FreeRTOS expects to have control over the SYSTICK timer.  You must use a different timer for the HAL tick.  It seems you might already have that since your existing FreeRTOS build works, but verify this.  And verify that the SYSTICK and whatever timer you use for the HAL tick point to the right interrupt handlers.

 

 

[Harvey White]

Missing information:

What would you like to see?

points:

1. Timebase source is TIM17 (programming habit)
2. HAL_Tick interrupt works as advertised
3. I do nothing (that I know of) to change the hardware interrupts of anything.
4. The item that is NOT changing is the sTickCount.  it seems very happy to stay at zero.  The delay until fails because the routine thinks it’s being asked for a negative delay.  
5. I haven’t been able to figure out what should be incrementing it.
6. This seems to be something to do with either the cmsis-os2 wrapper or something buried in FreeRTOS.
7. Assuming that it’s not a hardware priority, then some software is making assumptions
8. changing a task (LED DELAY) priority to either 1, 24 (normal), or 30 makes no difference.  
9. it’s doing task switching, but the delay within that task is what’s not working.