Hi Guys, I’m working on dual-core ZYNQ equipped with FreeRTOS v10.1.1. I would like to disable interrupt nesting capability but I still need to assign a priority to interrupt. The idea is that, if an interrupt is being serviced and other interrupts becomes pending in GIC controller, the next IRQ to be serviced soon after current ISR completes is the one pending with highest priority . looking at FreeRTOS port I think this is possible by moving the interrupt re-enable instruction after servicing the interrupt. Is this correct? Does it leads to some problems? Thanks in advance Bucky ~~~ void vApplicationFPUSafeIRQHandler( uint32t ulICCIAR ) { extern const XScuGicConfig XScuGicConfigTable[]; static const XScuGicVectorTableEntry *pxVectorTable = XScuGic_ConfigTable[ XPAR_SCUGIC_SINGLE_DEVICE_ID ].HandlerTable; uint32_t ulInterruptID; const XScuGic_VectorTableEntry *pxVectorEntry; /* Original Code below */

if 0

/* Re-enable interrupts. */
__asm ( "cpsie i" );

endif

/* The ID of the interrupt is obtained by bitwise anding the ICCIAR value
with 0x3FF. */
ulInterruptID = ulICCIAR & 0x3FFUL;
if( ulInterruptID < XSCUGIC_MAX_NUM_INTR_INPUTS )
{
    /* Call the function installed in the array of installed handler functions. */
    pxVectorEntry = &( pxVectorTable[ ulInterruptID ] );
    pxVectorEntry->Handler( pxVectorEntry->CallBackRef );
}

if 1 /* My Modification */

__asm ( "cpsie i" );

endif

} ~~~

The code you have commented out with the ‘#if 0’ is optional in that, if you remove it, interrupts don’t become re-enabled until the currently executing interrupt handler exits. I would imagine then that moving the cpsie i to the end of the function is safe and will have the effect you want – with the caveate I have neither tried it or studdied it. Alternatively you could just not have the cpsie i instructino at all – but that would be less efficient as the itnerrupt would exit and then re-enter if another was pending.

Hi Richard, Thanks for your answer, I’ll give it a try.