Nios® V/II Embedded Design Suite (EDS)
Support for Embedded Development Tools, Processors (SoCs and Nios® V/II processor), Embedded Development Suites (EDSs), Boot and Configuration, Operating Systems, C and C++

Delayed Interrupt

Altera_Forum
Honored Contributor II
2,772 Views

Nios-II response to Continuous interrupt is delayed (sometime), due to this i am loosing my data  

 

what precaution should i take to handle this issue 

 

please have a look on print screen of my LA 

 

 

earlier i am struggling with missing interrupt now i am getting interrupt but  

their response time vary even though i have given best possible priorities 

 

Regards 

 

kaushal
0 Kudos
14 Replies
Altera_Forum
Honored Contributor II
632 Views

It's not easy to help you without knowledge of your system implementation. I can only make a few guesses. 

First of all, the delay is in the 2us range. This short time is very difficult to manage in software.  

You excluded this delay is due to higher priority interrupts, but common hw processes, like bus arbitration, memory burst accesses or other unpredictable events can lead to a non neglectable delay in this range. 

What's you processor system clock frequency? Is Nios the only bus master or do you have dma? 

Please also specify where the irq comes from. Is this a PIO interrupt? And how do you read the data being lost?
0 Kudos
Altera_Forum
Honored Contributor II
632 Views

Is there any other sources of interrupt in your system? In that case there isn't a lot you can do, when the CPU is already processing an interrupt it won't be interrupted again. 

Do you realise that your CPU is spending more than 50% of its time in interrupt processing? It's not really what I would call an efficient design.
0 Kudos
Altera_Forum
Honored Contributor II
632 Views

 

--- Quote Start ---  

Is there any other sources of interrupt in your system? In that case there isn't a lot you can do, when the CPU is already processing an interrupt it won't be interrupted again. 

Do you realise that your CPU is spending more than 50% of its time in interrupt processing? It's not really what I would call an efficient design. 

--- Quote End ---  

 

 

No, this is the only interrupt source in my system
0 Kudos
Altera_Forum
Honored Contributor II
632 Views

Use signaltap to monitor the code addresses, they might show what is happening.

0 Kudos
Altera_Forum
Honored Contributor II
632 Views

 

--- Quote Start ---  

It's not easy to help you without knowledge of your system implementation. I can only make a few guesses. 

First of all, the delay is in the 2us range. This short time is very difficult to manage in software.  

You excluded this delay is due to higher priority interrupts, but common hw processes, like bus arbitration, memory burst accesses or other unpredictable events can lead to a non neglectable delay in this range. 

What's you processor system clock frequency? Is Nios the only bus master or do you have dma? 

Please also specify where the irq comes from. Is this a PIO interrupt? And how do you read the data being lost? 

--- Quote End ---  

 

 

What's you processor system clock frequency? 165mhz 

Is Nios the only bus master or do you have dma? yes, nios the only bus master i do not have any dma 

Please also specify where the irq comes from. Is this a PIO interrupt? yes this is a pio interrupt 

And how do you read the data being lost? its visiable on la and at receiver i am not getting data also 

At every interrupt I read 2D array ImgBuff[460][640] 

do { if(edge_capture) { //Clear generated interrupt edge_capture = 0; IOWR_ALTERA_AVALON_PIO_DATA(TEMP_OUT_BASE,1); //(shown on LA) IOWR_ALTERA_AVALON_PIO_DATA(DATA_BASE,ImgBuff);//(shown on LA) Count++; } if(Count == PktSize) //check end of packet-data { Count = 0; //Point to Start of packet data LPktCount++; //Increment packet Count } IOWR_ALTERA_AVALON_PIO_DATA(TEMP_OUT_BASE,0); //(shown on LA) }while(LPktCount != (PktCount+1));
0 Kudos
Altera_Forum
Honored Contributor II
632 Views

Is below code is correct for using Enhanced Interrupt ....as while compiling there is no error but during porting this code to nios downloading process stuck at 80% and nothing will happen afterword 

 

i found through altera literature that using enhance interrupt we may significantly improve our interrupt response time 

 

//------------------------------------------- //#ifdef LOAD_DATA_BASE # ifdef ALT_ENHANCED_INTERRUPT_API_PRESENT static void handle_load_data_interrupts(void* context)# else static void handle_load_data_interrupts(void* context, alt_u32 id)# endif { /* Cast context to edge_capture's type. It is important that this be declared volatile to avoid unwanted compiler optimization. */ volatile int* edge_capture_ptr = (volatile int*) context; // IOWR_ALTERA_AVALON_PIO_IRQ_MASK(LOAD_DATA_BASE, 0xf ); /* Store the value in the Button's edge capture register in *context. */ *edge_capture_ptr = IORD_ALTERA_AVALON_PIO_EDGE_CAP(LOAD_DATA_BASE); /* Reset the Button's edge capture register. */ IOWR_ALTERA_AVALON_PIO_EDGE_CAP(LOAD_DATA_BASE, 0XF); /* Read the PIO to delay ISR exit. This is done to prevent a spurious interrupt in systems with high processor -> pio latency and fast interrupts. */ IORD_ALTERA_AVALON_PIO_EDGE_CAP(LOAD_DATA_BASE); } /* Initialize the load_pio. */ static void init_load_pio() { /* Recast the edge_capture pointer to match the alt_irq_register() function prototype. */ void* edge_capture_ptr = (void*) &edge_capture; /* Enable all 4 button interrupts. */ IOWR_ALTERA_AVALON_PIO_IRQ_MASK(LOAD_DATA_BASE, 0xf); /* Reset the edge capture register. */ IOWR_ALTERA_AVALON_PIO_EDGE_CAP(LOAD_DATA_BASE, 0xF); /* Register the interrupt handler. */ # ifdef ALT_ENHANCED_INTERRUPT_API_PRESENT alt_ic_isr_register(VIC_IRQ_INTERRUPT_CONTROLLER_ID, VIC_IRQ, handle_load_data_interrupts, edge_capture_ptr,0x0); # else alt_irq_register( VIC_IRQ, edge_capture_ptr, handle_load_data_interrupts); # endif } //#endif /* LOAD_DATA_BASE */ Main() { printf("\nInitillize the Enhanced Interrupt..\n"); init_load_pio(); }
0 Kudos
Altera_Forum
Honored Contributor II
632 Views

 

--- Quote Start ---  

 

i found through altera literature that using enhance interrupt we may significantly improve our interrupt response time 

 

--- Quote End ---  

 

I think you could get much better speed improvement if you place ImgBuff, isr and other time critical code in onchip memory and connect to Nios with Tightly Coupled ports.
0 Kudos
Altera_Forum
Honored Contributor II
632 Views

 

--- Quote Start ---  

I think you could get much better speed improvement if you place ImgBuff, isr and other time critical code in onchip memory and connect to Nios with Tightly Coupled ports. 

--- Quote End ---  

 

 

Sorry i haven't much idea about how to put "ImgBuff, isr and other time critical code in onchip memory and connect to Nios with Tightly Coupled ports" in onchip memory though i have onchip memory in my sopc 

 

please give some clue or literature which guide me in this direction.
0 Kudos
Altera_Forum
Honored Contributor II
632 Views

Open Qsys and go to Nios properties.  

Add a tightly coupled (TC) code port and possibly a TC data port. 

Close Nios properties. 

Add 2 onchip memories and connect one of them to Nios TC code port and the other to TC data port. 

In your case I believe 4kByte for TC code memory is enough. 

TC data must be large enough to store ImgBuff, then size >= (460 x 640 x 4) if you need 32bit data; this would be more than 1MByte and probably exceeds your fpga resources, so you can not use TC data and you have to keep data in ddr2. 

Now, let's say you named tc_code your TC memory component.  

Then place the following directive just after the declaration of a function you want to be executed in TC memory: 

int main(void) __attribute__ ((section (".tc_code"))); 

The same can be done with variable you want to be accessed very very fast: 

int fastBuffer[256] __attribute__ ((section (".tc_data")));
0 Kudos
Altera_Forum
Honored Contributor II
632 Views

You could also monitor the CPU avalon master's waitrequest signal. The stall you are seeing could come from a peripheral that is freezing the CPU, the SDRAM controller doing a refresh cycle for example.

0 Kudos
Altera_Forum
Honored Contributor II
632 Views

Actually, if you look at the timing trace you'll see that there is a relatively long time between the interrupt request and your ISR running. 

Throw away the Altera interrupt code and write your own. 

Even if you have to save/restore the registers it shouldn't take anywhere near the length of time that code takes. 

If you can use an 'alternate register set' then you should be able to get interrupt entry/exit down to a few clocks. 

(even without it you might manage to write an asm ISR that doesn't use any registers that the main code uses)  

 

I also presume you are not running the JTAG debugger at all - it wouldn't surprise me if that doesn't take some interrupts. 

 

You might also want to look at adding a short fifo (a couple of items) on the input and output - that will mean that the system will handle a longer interrupt latency.
0 Kudos
Altera_Forum
Honored Contributor II
632 Views

 

--- Quote Start ---  

Open Qsys and go to Nios properties.  

Add a tightly coupled (TC) code port and possibly a TC data port. 

Close Nios properties. 

Add 2 onchip memories and connect one of them to Nios TC code port and the other to TC data port. 

In your case I believe 4kByte for TC code memory is enough. 

TC data must be large enough to store ImgBuff, then size >= (460 x 640 x 4) if you need 32bit data; this would be more than 1MByte and probably exceeds your fpga resources, so you can not use TC data and you have to keep data in ddr2. 

Now, let's say you named tc_code your TC memory component.  

Then place the following directive just after the declaration of a function you want to be executed in TC memory: 

int main(void) __attribute__ ((section (".tc_code"))); 

The same can be done with variable you want to be accessed very very fast: 

int fastBuffer[256] __attribute__ ((section (".tc_data"))); 

--- Quote End ---  

 

my Qsys not opening my sopc file it display only clock is it some kind of license issue i am using quartus 11.0 sp1
0 Kudos
Altera_Forum
Honored Contributor II
632 Views

 

--- Quote Start ---  

my Qsys not opening my sopc file it display only clock is it some kind of license issue i am using quartus 11.0 sp1 

--- Quote End ---  

 

How did you design your system before? 

IIRC Qsys in Quartus 11.0 doesn't open automatically the design and presents you the basic clock+reset default system; you simply have to load your actual design from File menu. 

If the TC solution is not enough for you I'd follow dsl's tips, especially the alternate register set and the fifo.
0 Kudos
Altera_Forum
Honored Contributor II
632 Views

You probably also want to arrange for the 'small data segment' to be in the on-chip memory and use section names ".sdata.*" so that the compiler will generate %gp relative addressing for the accesses. 

Unfortunately the Altera builds of the compiler will not use %gp relative addressing for members of structures or arrays allocated to the 'small data' section. There are some gcc patches on the wiki that will make gcc use %gp relative addressing for structure members (constant offset from %gp), but not for arrays. 

An alternative is to put all the global data inside a single structure (max 32kb) and use a global register variable to access it. gcc can generate better code for this than when using 'small data'. With care you can use %gp for the global register!
0 Kudos
Reply