Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem


Problems while enabling nested interrupts on Zynq-7000

Posted by devil1989 on July 21, 2017

Hello, I am working with a Zynq-7000 and FreeRTOS 8.2.3. I would like to enable nested interrupts but I am experiencing some problems.

As Xilinx AR54128 (https://www.xilinx.com/support/answers/54128.html) says, I call XScuGicCPUWriteReg(IntcInstancePtr, XSCGICBINPTOFFSET,0x03) during the interrupt controller initialization, before the XilExceptionInit(). Then, my ISR routine is something like this: ~~~ void Handler() { BaseTypet xTaskWokenByReceive = pdFALSE; BaseTypet xHigherPriorityTaskWoken = pdFALSE;


if(xQueueReceiveFromISR(<argA>, <argB>, &xTaskWokenByReceive) == pdTRUE)
	vTaskNotifyGiveFromISR(<argC>, &xHigherPriorityTaskWoken);
else if(xQueueReceiveFromISR(<argD>, <argE>, &xTaskWokenByReceive) == pdTRUE)
	vTaskNotifyGiveFromISR(<argF>, &xHigherPriorityTaskWoken);
	// Do nothing

/* If xHigherPriorityTaskWoken is now set to pdTRUE then a context switch * should be performed to ensure the interrupt returns directly to the highest * priority task. The macro used for this purpose is dependent on the port in * use and may be called portENDSWITCHINGISR(). */ XilDisableNestedInterrupts(); portYIELDFROMISR(xHigherPriorityTaskWoken); } ~~~ The priority of the related interrupt is equal to configMAXAPICALLINTERRUPT_PRIORITY. During the execution I get two assert errors: - Assert failed in file port.c, line 539 - Assert failed in file port.c, line 424

The first one comes from the first configASSERT of the function vPortValidateInterruptPriority(): ~~~ void vPortValidateInterruptPriority( void ) { /* The following assertion will fail if a service routine (ISR) for an interrupt that has been assigned a priority above configMAXSYSCALLINTERRUPTPRIORITY calls an ISR safe FreeRTOS API function. ISR safe FreeRTOS API functions must only be called from interrupts that have been assigned a priority at or below configMAXSYSCALLINTERRUPTPRIORITY.

	Numerically low interrupt priority numbers represent logically high
	interrupt priorities, therefore the priority of the interrupt must
	be set to a value equal to or numerically *higher* than

	FreeRTOS maintains separate thread and ISR API functions to ensure
	interrupt entry is as fast and simple as possible. */

	/* Priority grouping:  The interrupt controller (GIC) allows the bits
	that define each interrupt's priority to be split between bits that
	define the interrupt's pre-emption priority bits and bits that define
	the interrupt's sub-priority.  For simplicity all bits must be defined
	to be pre-emption priority bits.  The following assertion will fail if
	this is not the case (if some bits represent a sub-priority).

	The priority grouping is configured by the GIC's binary point register
	(ICCBPR).  Writting 0 to ICCBPR will ensure it is set to its lowest
	possible value (which may be above 0). */


The second one from the last configASSERT of the function vPortEnterCritical(): ~~~ void vPortEnterCritical( void ) { /* Mask interrupts up to the max syscall interrupt priority. */ ulPortSetInterruptMask();

/* Now interrupts are disabled ulCriticalNesting can be accessed
directly.  Increment ulCriticalNesting to keep a count of how many times
portENTER_CRITICAL() has been called. */

/* This is not the interrupt safe version of the enter critical function so
assert() if it is being called from an interrupt context.  Only API
functions that end in "FromISR" can be used in an interrupt.  Only assert if
the critical nesting count is 1 to protect against recursive calls if the
assert function also uses a critical section. */
if( ulCriticalNesting == 1 )
	configASSERT( ulPortInterruptNesting == 0 );

} ~~~

Does anyone know why I get those errors? Am I making some mistakes while setting the interrupt's priority? Thank you for the help!


Problems while enabling nested interrupts on Zynq-7000

Posted by rtel on July 21, 2017

I don't know what the XilEnableNestedInterrupts() and XilDisableNestedInterrupts() calls do, but have never had to use them myself to use nested interrupts.

Have you read the section on interrupts on the following page: http://www.freertos.org/Using-FreeRTOS-on-Cortex-A-Embedded-Processors.html - in particular make sure the vApplicationIRQHandler() function is enabling interrupts again before calling the handler installed for the interrupt.

Problems while enabling nested interrupts on Zynq-7000

Posted by devil1989 on July 24, 2017

Hi! Thanks for your answer. I knew that page and I read the section on interrupts. I do not have the function vApplicationIRQHandler() but I have another similar function that does similar things. ~~~ void FreeRTOSApplicationIRQHandler( uint32t ulICCIAR ) { extern const XScuGicConfig XScuGicConfigTable[]; static const XScuGicVectorTableEntry *pxVectorTable = XScuGicConfigTable[ XPARSCUGICSINGLEDEVICEID ].HandlerTable; uint32t ulInterruptID; const XScuGicVectorTableEntry *pxVectorEntry;

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

} ~~~ It seems a bit different from the function shown in the link you provided, but I cannot re-define it in my application as it is not a weak function.

Am I missing something? Thank you. Enrico

Problems while enabling nested interrupts on Zynq-7000

Posted by rtel on July 24, 2017

That handler is not re-enabling interrupts, so if you want to you nested interrupts you will have to re-enable interrupts in the handler function itself (that is, the function called by FreeRTOS_ApplicationIRQHandler()). Refer to the code on the page I linked to before to see how interrupts are re-enabled if you are not sure.

[ Back to the top ]    [ About FreeRTOS ]    [ Privacy ]    [ Sitemap ]    [ ]

Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.

Latest News

NXP tweet showing LPC5500 (ARMv8-M Cortex-M33) running FreeRTOS.

Version 10.1.1 of the FreeRTOS kernel is available for immediate download. MIT licensed.

View a recording of the "OTA Update Security and Reliability" webinar, presented by TI and AWS.


FreeRTOS and other embedded software careers at AWS.

FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Espressif ESP32

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers


STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

OpenRTOS and SafeRTOS

Xilinx Microblaze and Zynq partner