Scheduler priority in higher then MAX_SYSCALL

Kernel
1

Hi,

I am working with cortex-m4, Please let me know what will be the effects if the scheduler is working in SysTick interrupt (priority 0 Highest) and configMAX_SYSCALL_INTERRUPT_PRIORITY is set to 5.

I have doubt as I have read “full interrupt nesting model is achieved by setting configMAX_SYSCALL_INTERRUPT_PRIORITY above (that is, at a higher priority level) than configKERNEL_INTERRUPT_PRIORITY. This means the FreeRTOS kernel does not completely disable interrupts, even inside critical sections.”

We do not have configKERNEL_INTERRUPT_PRIORITY but still scheduler in running on higher priority then configMAX_SYSCALL_INTERRUPT_PRIORITY. Please guide.

2

Hi there,

what is unclear about the documentation?

Your service interrupt handler MUST POSITIVELY run on the LOWEST interrupt priority as it may only interrupt tasks, not other ISRs.

Every ISR that does use OS services (trivially including the sys tick handler) MUST POSITIVELY execute LOWER than configMAX_SYSCALL_INTERRUPT_PRIORITY.

If you don’t follow those guidelines, you risk all kinds of random crashes and other unpredictable phenomena.

As for the numbering of Cortex priorities, I think that this has been discussed so frequently here that we don’t need to discuss it again.

3

As mentioned by @RAc there are many posts here in the forum regarding interrupt priorities especially related to wide spread Cortex-M MCUs.
Search for configMAX_SYSCALL_INTERRUPT_PRIORITY and/or configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY.

However, did you already read the FreeRTOS docs (in case you’re using a Cortex-M MCU as I suppose) RTOS for ARM Cortex-M ?
IMO this post Understanding priority levels of ISR and FreeRTOS APIs - #16 by aggarg contains a good and easy to understand explanation. There are more…

BTW: You should always include the MCU or the processor core and the FreeRTOS version you are using when asking for help.

1 Like
4

Hi sir,

Thanks for the prompt reply.

I am using Renesas MCU R7FA6M3AF3CFB and core cortex-m4 with FreeRTOS version 10.3.0

numbering of Cortex priorities is clear to me.

We got the FreeRTOS port from Renesas and the scheduler is running in SysTick interrupt and its priority in -1 which is higher then configMAX_SYSCALL_INTERRUPT_PRIORITY. That’s why i got confused.

Now As i understand we need to call the scheduler from the lowest interrupt.

As per the quote

I still have one more doubt As in our current port we are using PendSV_Handler for context switch do we need to change it too? As PendSV_Handler is a higher priority interrupt.

As I can Recall in STMController port too we use PendSV_Handler.

Thanks again.

6

Please show some source.

7

let me re-phrase my doubt,

My current system architecture.

        Logical      Numerical
       Priorities    Priorities
       +--------+    +-------+             ^
	   |		|	 |		 |			   |
       |        |    |       |             |
       |        |    |       | <---------------- PendSV Priority
       |        |    |       |             |
       |        |    |       | <---------------- SysTick Priority 
       |        |    |       |             |		   
       |        |    |       |             |
       |        |    |       |             | Not masked by FreeRTOS kernel
       | Higher |    | Lower |             | ( FreeRTOS APIs can not be
       |        |    |       |             |    called from these ISRs. )
       |        |    |       |             |
	   |        |    |       |             |
       |        |    |       |             |
       |        |    |       |             v
       +--------+    +-------+ <---------------- configMAX_SYSCALL_INTERRUPT_PRIORITY
       |        |    |       |             ^
       |        |    |       |             |
       |        |    |       |             |
       |        |    |       |             |
       | Lower  |    |Higher |             | Masked by FreeRTOS Kernel
       |        |    |       |             | ( FreeRTOS APIs can be
       |        |    |       |             |    called from these ISRs. ) 
       |        |    |       |             |
       |        |    |       |             |
       |        |    |       |             |
       |        |    |       |             |
       +--------+    +-------+             v

In the SysTick Handler scheduler is being called.

/* Increment the RTOS tick. */
if (xTaskIncrementTick() != pdFALSE)
{
    /* A context switch is required.  Context switching is performed in
     * the PendSV interrupt.  Pend the PendSV interrupt. */
    SCB->ICSR = SCB_ICSR_PENDSVSET_Msk;
}

And PendSV interrupt is being used for the context switch.

As I have understood I need to call the scheduler from the lowest interrupt.

Do I also need to change anything regarding Context switch as it is being called from logical higher Interrupt i.e. PendSV Hendler?

8

Oh I see, that’s your fallacy…

The ISR is not being CALLED at that point, just SCHEDULED (marked pending on the MCU level). As soon as no higher pri ISR is running (which means no sooner than the sys tick isr has terminated, but possibly even later if other ISRs cut in in the mean time), the pending service ISR is invoked. That’s the beauty of it!

1 Like
9

PendSV and SysTick interrupt priorities are different to the FreeRTOS default if really configured this way.
FreeRTOS uses configKERNEL_INTERRUPT_PRIORITY for them, which is the lowest interrupt priority. I can’t imagine why Renesas should have changed that.
There are very good reasons setting them to the lowest interrupt priority e.g.

configKERNEL_INTERRUPT_PRIORITY is set to the lowest urgency interrupt level in the system. So this means the interrupts of the kernel (SysTick and context switches) run with the lowest possible urgency. This makes sense as the kernel should not block or interrupt the other interrupts in the system.

1 Like
10

Thanks a lot. I will change the scheduler interrupt and check the PendSV functionality.