Hello all. I’ll try to be brief with my problem. I’m working on a zynq 702 board which is programmed with a custom hardware. Currently i’m adapting the CORTEXA9ZYNQ demo for my purposes. The hardware, on certain occasions, raises an interrupt which i’m trying to catch and by using a semaphore to synchronize my task with my hardware. So far i have managed to catch the interrupt but i’m getting an assertion failure at tasks.c:2360 (configASSERT( pxUnblockedTCB );) My code: Modified Demo/CORTEXA9ZynqZC702/RTOSDemo/src/FreeRTOStick_config.c: vConfigureTickInterrupt()

// Install the foo ISR.
extern void rtos_fooISR(void *data) /*__attribute__ ((isr))*/;
/// (notice i don't use the __attribute__ (isr), more on this later)

XScuGic_SetPriorityTriggerType( &xInterruptController, 90, (configMAX_API_CALL_INTERRUPT_PRIORITY) << portPRIORITY_SHIFT, ucRisingEdge);
xStatus = XScuGic_Connect( &xInterruptController, 90, (Xil_ExceptionHandler) rtos_fooISR, NULL);
configASSERT( xStatus == XST_SUCCESS );
( void ) xStatus;
XScuGic_Enable(&xInterruptController, 90);

Somewhere in main i initialize the binary semaphore: BaseType_t status; (void) status;

/// Initialize semaphore
foo_Semaphore = xSemaphoreCreateBinary();
configASSERT(foo_Semaphore != NULL);

status = xSemaphoreGive(foo_Semaphore);
configASSERT(status == pdTRUE);

Here is the ISR: void rtosfooISR(void *data) { static BaseTypet xHigherPriorityTaskWoken = 0; static volatile unsigned int *reg_addr = (unsigned int *)(BASE + foo_INTERRUPT); (void) data; /// Clear interrupt *reg_addr = 0x1; /// “give” semaphore /// xil_printf(“gnr”); xSemaphoreGiveFromISR(foo_Semaphore, &xHigherPriorityTaskWoken); portYIELD_FROM_ISR(xHigherPriorityTaskWoken); } And this is the function the task calls when it wants to synchronize with the hardware void rtoswaitForfoo(void) { xilprintf(“tnr”); xSemaphoreTake(fooSemaphore, portMAXDELAY); } Is my code correct or i’m using a hack without being aware of it? Any idea why i get the assertion failure? Also when i declare the rtos_fooISR function with the attribute((isr)) it appears that the interrupt stays on for ever. Why is that? Thanks for your time.

I cannot see anything that is obviously wrong in your code. You definitely don’t want to use the attribute on your ISR handler as that will cause the compiler to add interrupt handling prologue and epilogue code that will not be compatible with the FreeRTOS interrupt entry point. There is a single interrupt entry point that already contains the necessary prologue code before calling your handler as a standard C function. The assert that is failing is inside the xTaskRemoveFromEventList() function – which will be getting called from your interrupt handler, but probably from other places too. Is the assert failing from inside your handler (so from inside the xSemaphoreGiveFromISR() function)? Regards.

Is the assert failing from inside your handler (so from inside the xSemaphoreGiveFromISR() function)?

I’m not sure about that. How can i check it?

Two ways. When you hit the assert in the debugger either look at the call stack to see the function call path to the assert or step out of the assert function in the debugger to see where it returns too. This is Eclipse right? If so the call stack is shown in the threads window, normally the top left window in the debug perspective.

When you hit the assert in the debugger 

I’m not sure how to use the debugger. Currently i write a single image file which contains the hw spec the rtos plus a small library which is my task (which is the only task i create) on an sd card and boot the zynq board with it.

This is Eclipse right?

Yes i use the eclipse but just to compile the project. After that i write the image on the sd card. Removing the xSemaphoreGiveFromISR(fooSemaphore, &xHigherPriorityTaskWoken); from the ISR the task (as excpected) hangs for ever in the rtoswaitForfoo() function. If i remove the xSemaphoreTake(fooSemaphore, portMAXDELAY); from the rtos_waitForfoo() function too, then the same assertion failure happens. Thanks for the replies. I really appreciate it.

Alright i believe i have found the root of my problem. It appears that i was causing a memory corruption by writing outside an array allocated with heap_1 Thank you for your replies and your time.