Interrupt handler is not Notifying after 98 times in Zynq702

krishnam1 wrote on Friday, March 03, 2017:


Iam using Zynq702, in this we have an hardware that can communicate with the Processing System (PS) using AXI bus.PS is AXI Master.

Data Flow and Hardware Details as mentioned below:

Data From Wire–> Programmable Logic (FPGA) – > BRAM --> AXI Interconnect --> PS
After the above sequence the data is made available to the PS(ARM Core).
Interrupt is sent to PS to start fetching using SCUGuic using GPIO from PL to PS.

In FreeRTOS (8.2.3) created 1 interrupt and 1 task.
Priority of this interrupt task is greater than RTOS timer interrupt.
In this Interrupt routing FromISR function only used to notify the Task.

Below are the obervation.

1.Works fine for 98 times, interrupt able to notify the task
2.On 98th time interrupt occurs and NotifyFromIsr also called but the break point is not hitting the task.

As a RTOS it should not fail to start any task from the interrupt.

I don’t know why it failing in the FreeRTOS.
Tried to debugging using StateViewer but not able to see for FreeRTOS.
Is there any way to fix this issue.


rtel wrote on Sunday, March 05, 2017:

Is it always on the 98th interrupt?

Can you show the task code, where the notification is received, and the interrupt code, where the notification is sent.

Do you have configASSERT() defined and stack overflow checking switched on?

krishnam1 wrote on Monday, March 06, 2017:


Thanks for the quick response.

Yes, it is 98th time.

Observed that frequency of this interrupt is <400uS.
Also interrupt to task swtiching time for the working case is 2.6uS

Yes, configASSERT() and stack overflow checking switched on.

configTotal_HEAP_SIZE set to 4MB in FreeRtosConfig.h.

This particular task stak size is configured to 12KB.

It would be great help if you can give any hints for debugging this behavior.


rtel wrote on Wednesday, March 08, 2017:

Apologies for the delay in your post appearing. For some reason it went
into a moderation queue, even though its not supposed to.

As its so consistent can you add a counter into your code to enable you
to put a break point no the 98th occurrence, and then step into the code
from there to try and determine the route cause?

Something like:

if( counter == 98 )
__asm volatile( “NOP” ); // Place breakpoint here.

krishnam1 wrote on Thursday, March 09, 2017:


sure, i will try & let you know.
Observed that it is entering to abort handle when we are trying to access the same memory at 98th time…
If i comment axi bram buffer accessing inside task then i wont see the data abort,

To ensure it is not an freertos isuue is there any way I can check tcb or task information when reaches 98th count.

Does freertos capable to handle frequent context switching at every 400us?