Interrupts not working when booting FreeRTOS with barebox on Zynq Ultrascale+ on A53 on EL1_NONSECURE Mode

Partners & Sponsors Xilinx
1

Hello everyone,
I am currently trying to get Interrupts working on the freeRtos A53 Xilinx Port when booting in EL1_NONSECURE Mode from barebox. This is the freeRtos implementation from Xilinx we are using: https://github.com/Xilinx/embeddedsw/tree/master/ThirdParty/bsp/freertos10_xilinx/src/Source/portable/GCC/ARM_CA53

The only interrupt that seems to work is the Tick Interrupt from FreeRTOS itself. It is initialised in essentially 3 lines of code `xPortInstallInterruptHandler(configTIMER_INTERRUPT_ID,
( Xil_InterruptHandler ) FreeRTOS_Tick_Handler,
( void * ) &xTimerInstance);
/* The priority must be the lowest possible. */
XScuGic_SetPriorityTriggerType( &xInterruptController, configTIMER_INTERRUPT_ID, portLOWEST_USABLE_INTERRUPT_PRIORITY << portPRIORITY_SHIFT, ucLevelSensitive );

vPortEnableInterrupt(configTIMER_INTERRUPT_ID);`

Using the same functions I am not able to initialise other interrupts. I am fearing it has something to do with the Exception Level 1, because when downloading with JTAG in EL3 interrupts do work(Only tested software interrupts). When looking at the underlying Generic Interrupt Controller, it seems to forward only Group 0 interrupts. Could that be a problem?

2

Did you define EL1_NONSECURE in your project? https://github.com/Xilinx/embeddedsw/blob/master/ThirdParty/bsp/freertos10_xilinx/src/Source/portable/GCC/ARM_CA53/portASM.S#L182

3

Yes, it is defined in the bspconfig.h

4

Does somebody know why that needs to be? Wouldn’t it make more sense to give it configMAX_API_CALL_INTERRUPT_PRIORITY ??

5

Where is the comment you pasted into your last post? Is it in FreeRTOS code, Xilinx code or your code? if it is in FreeRTOS code please link to the line in Github.

6

It is in FreeRtos Port from Xilinx for the A53. Right here is the line: https://github.com/Xilinx/embeddedsw/blob/3728f546f178a1bcd91cf6efc9f8921447846cec/ThirdParty/bsp/freertos10_xilinx/src/Source/portable/GCC/ARM_CA53/portZynqUltrascale.c#L114

7

That is setting the priority of the interrupt that generates the RTOS tick. I think it is sound advice to have this as the lowest priority, otherwise tick tick count could change during processing of other interrupts.

8

Wouldn’t then the kernel need the highest priority so it cannot be interrupted? Or what do you mean with the tick count could change?

And wouldn’t hardware Interrupts thats use FreeRTOS Api functions need an even lower priority than the kernal tick? If so how would that work if the kernal tick has the lowest priority?

9

The kernel is not a task nor an interrupt, so there is no sense in “kernel needs a priority.”

The service interrupt (if present) MUST have the lowest priority because it is from there a context switch is being initiated, and a context switch can only “return to” a valid task context.

From my understanding “the tick count could change” means that when an interrupt lower than the sys tick priority reads the sys tick and then gets interrupted by the sys tick interrupt, the system timer and that interrupt have different undertandings of the system time which may pose problems. The sys tick handler can theoretically run at any priority, but even though it is fine tuned to eat up as few CPU cycles as possible, it will adversely affect all ISRs running at lower priority by “stealing” cycles.

When the scheduler and interrupts must ensure uninterruptable sequencing, they do so with the aid of the critical section.

10

Okay thank you! That means kernel tick should have have a lower priority than every other interrupts. Thats all I need to know.