Interrupt priority setting on ATMEL D51 board

Kernel
1

manu38 wrote on Friday, February 08, 2019:

Using FreeRtos on board atmel D51, I don’t manage to set IRQ priority such that I can call few “xxxFromISR()” function from interrupt handler.
I keep being stuck on the assert
configASSERT(ucCurrentPriority >= ucMaxSysCallPriority);
(ucCurrentPriority is 0, ucMaxSysCallPriority is 128)

I know that this is kind of classical problem, however despite various reading both on FreeRTOS and ATMEL side discussing trouble around this, I don’t manage to fix this.

My FreeRTOS config looks correct (can share some part if required).
I’m setting the priority of my IRQ (41) to configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY (128) and from what I can check with the debugger, it works. (uisng CMSIS NVIC_SetPriority() function)
My interrupt handler is called when interrupt is triggered; however, when calling some FreeRTOS FromISR routine from there, the interrupt priority seen is not the one set (still 0).
NVIC prio table is still correct;

That’s why I’m missing something: the IRQ prio set seems not to be the one expected by FreeRTOS.
Can anyone advise on what I’m missing ?

Thanks

2

rtel wrote on Friday, February 08, 2019:

I presume this is the page you are referring to?

I’m setting the priority of my IRQ (41) to
configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY (128)

Which is hex 0x80, or binary 1000 0000, so basically a value that has
already been shifted to the most significant bits (see link above).

I would need to know the value of __NVIC_PRIO_BITS to know what logical
priority that represented.

(uisng CMSIS NVIC_SetPriority() function)

Not a function I use myself, but if I recall correctly, this function
requires the logical interrupt priority BEFORE it is shifted up to the
most significant bits. Hence - your code is not going to work - but you
knew that already ;o)

Basically you are mixing the way the priority registers want the
priority to be specified (priority value in the most significant bits)
with the way the function being used to set the priority wants the value
to be specified (priority value in the least significant bits).

3

manu38 wrote on Monday, February 11, 2019:

I presume this is the page you are referring to?
RTOS for ARM Cortex-M

Yes, one of them indeed.

I would need to know the value of __NVIC_PRIO_BITS to know what logical
priority that represented.

It is set to 3 (which match the datasheet)

Not a function I use myself, but if I recall correctly, this function
requires the logical interrupt priority BEFORE it is shifted up to the
most significant bits. Hence - your code is not going to work - but you
knew that already ;o)

Basically you are mixing the way the priority registers want the
priority to be specified (priority value in the most significant bits)
with the way the function being used to set the priority wants the value
to be specified (priority value in the least significant bits).

Indeed, I’m more or less aware of this without knowing which one is correct as none of my trials works: my understanding is that I should set a priority >= 4 (which is 100 in 3-bits binary). But whatever the value I used when calling NVIC_SetPriority() (128, 3, 5, 7, …), I always fall into the assert with ucCurrentPriority == 0 .

Also, I noticed that even if in the callstack, I can see that I’m in my interrupt handler (of interrupt number 41), in FreeRTOS level, the prority that is looked up here (when the assert failed):
ucCurrentPriority = pcInterruptPriorityRegisters[ulCurrentInterrupt];
is number 37 (ulCurrentInterrupt == 37) and priority is 0

Here, I’m missing the point about how IRQ 41 becomes 37 when coming here ?

Second point is that if I look at the other entries in the table pcInterruptPriorityRegisters, I don’t see any that seems to be the one I set with NVIC_SetPriority() ?

Thanks,

4

rtel wrote on Monday, February 11, 2019:

I don’t think you mentioned which version of FreeRTOS you are using.
Can you ensure you are using the very latest official release as that
contains the most configASSERT() calls to check nearly everything, maybe
even everything, that can be mismatched between your configuration and
the hardware. That might catch something at initialisation time.

5

manu38 wrote on Tuesday, February 12, 2019:

I found my mistake: I’m using an external interrupt controller and 41 is the IRQ number in the EIC, but not the one seen by NVIC.
Using 41 in NVIC routine was my mistake.
My bad, thanks anyway !

6

rtel wrote on Tuesday, February 12, 2019:

Appreciate you taking the time to report back.