NIOS + IRQ + custom component

[Altera_Forum]

Hi, I'm trying to interrupt a Nios Prosessor whit a Custom Component and setup a successful interrupt routine. But I can't Do it.  

 The problem is that i can't find a complete example of a custom component connected to a NIOS II processor who succesfuly call a ISR.   Can someone help me?  Jairo

[Altera_Forum]

Dear all, 

 Ah I know what the problem is. Actually it was my silly mistake >.< . I missed watching some signals in the SignalTap.  Now I have another problem. In my design, whenever the interrupt occurs, as the kohagan & dsl's previous posts suggestion I read the IRQ bit, send signal (pair of write and writedata) to clear the IRQ bit. However, the signal (write) to clear the IRQ bit never comes. Are there anybody know what cause this condition? Is there something wrong with my C code that I posted before?  Thanks

[Altera_Forum]

--- Quote Start ---   There are some systems [1] where it is possible to exit the ISR before the write (2) has propogated far enough to actually cause the IRQ line to be deasserted. This can cause 'splurious' ISR messages under certain loads.  [1] eg when the write gets 'posted' on some bus, and the check (3) involves looking in shared memory (typical of ethernet receive).  --- Quote End ---    ah I just remember..:eek: maybe my case is same as like what dsl said. The program exits the ISR earlier before the 'write' signal comes. Now I'm modifying my components interface signal behavior. Let me see whether it will fix my problem or not..:confused:  Thanks

[Altera_Forum]

On the nios your avalon slave will see the write cycle before the cpu executes the next instruction (provided you've not gone through the cache!). 

You might want to check reads and writes from the nios to your mm slave work properly!

[Altera_Forum]

Yap, it has been confirmed. The problem is like what you wrote. From the SignalTap it is noticed that the write signal comes very late. Are there any way to make the write signal come faster? 

 Thanks

[Altera_Forum]

It isn't obvious to me where the delay might be. 

One common way to wait for a 'posted' write to complete is to issue a read of the same address (for uncached locations the written data can't be used to satisfy the read). However the nios doesn't do posted writes to the avalon fabric (it would be a useful feature, even if only one write were posted and all reads waited). Are you 100% sure the write isn't going through the data cache?

[Altera_Forum]

Hi dsl, 

 Is it possible that the interrupt register is already in active condition in the beginning program? Somehow I found that somehow my interrupt register was in active condition (the actual interrupt condition didn't happen yet). I tried to clear the interrupt register in the beginning of my program, but it didn't work (it seems because the write signal came late).. I've checked my component hardware many times, there is nothing wrong with it :(  Please help me if you know what caused this problem.. Thanks

[Altera_Forum]

The initial state will depend on the reset state of your logic. 

So you need to clear it on sopc reset (and maybe from the nios soft reset). Having a separate software written 'interrupt enable' register may help here. I've not actually used the nios interrupt controller - so don't know if it has an IE mask, and have NFI what any altera startup code does!  I don't have any external devices that are time-critical enough to require the cost of taking an interrupt. The code's idle loop checks the device registers directly (instead of looking at state set by an ISR).  This avoids any need for disabling interrupts and cuts down on the number of cpu cycles needed to do the work (which is very critical for my code).

[Altera_Forum]

Hi dsl, 

 Thanks for your reply.    --- Quote Start ---   I don't have any external devices that are time-critical enough to require the cost of taking an interrupt. The code's idle loop checks the device registers directly (instead of looking at state set by an ISR).   --- Quote End ---    Could you show me an example of checking the device register during the idle loop? I think if we want to check the register, we have to keep checking it except we apply an interrupt to sign if there is any changes in the register's content.  Hmm...currently I have some problems with my design :   1. Somehow the SignalTap couldn't detect the trigger that I've set (I set the interrupt signal as the trigger). The interrupt signal's clock was 150 MHz, and I set 300 MHz as the sampling frequency for the SignalTap. Few days my SignalTap still could catch the trigger, now I don't know why it became like this. I'm sure that I didn't do any critical hardware modification related with SignalTap function.  When I checked the SignalTap instantaneously it showed that there was IRQ signal change, so in actual the trigger really occured but the SignalTap couldn't catch it. :confused:  2. The IRQ keeps coming, even I try to clear it. It seems that the IRQ signal only clear within 1 clock, then it keeps active. About the possibility of interrupt redundancy (when the first interrupt isn't completely cleared, the second interrupt occur), I have tried to prevent it by setting large number of data that have to be processed before the interrupt occur. Any other idea about this? To find what causes this interrupt problem becomes more difficult, because the SignalTap can't detect the IRQ signal..:(  Please anyone....help me to figure out how to solve this interrupt problem ... :( Thanks

[Altera_Forum]

Hi all, 

 After several debug tests, I think my problem is consecutive IRQ.  Let me explain my current module :  I have a module which consists of two FIFOs (FIFO 1 and FIFO 2). This module receives input data from outside (from a DSP Board). In the beginning the input data will enter the FIFO 1. After receiving a number of data, let say 1 frame, the module will generate an IRQ. Then, the CPU will handle the IRQ in the ISR, and the data from FIFO 1 are read. For the next frame data, it will be written in the FIFO 2. Then, again after completely receiving 1 frame data, the module will generate IRQ and the data from FIFO 2 are read. For the next frame data, the input data will be written again in the FIFO 1. So the writing process between FIFO 1 and FIFO 2 happen alternately. Since the IRQ is still generated from the same module, the IRQ either from FIFO1 or FIFO2 are handled by the same ISR.  My problem now is when the ISR handles the IRQ from FIFO1, my IRQ signal keeps active. It seems the my program keep re-entering the ISR (so it likes consecutive IRQ). I've debugged my design & program and I can say that this situation is not caused by two interrupt that happens in the same time, because the writing duration for a FIFO is long enough. or in other words there is a long enough interval between two IRQ such that they don't overlap each other.  So are there anyone who can help me to solve this consecutive IRQ problem ?? :( :(  Thanks, I really appreciate any helps or suggestions.

[Altera_Forum]

Hey guys, 

Please, if someone still has BadOmen's IRQ example design, could you send it to me?  This is my email address:   I'd really appreciate your help!

[Altera_Forum]

Hi, 

Please send the example SOPC custom component with IRQ to moganesh at yahoo dot com. Thanks.

[Altera_Forum]

Hi, 

 I would appreciate a copy of the example SOPC custom component with IRQ , if available.  please send to: jose dot paza at connexa dot com dot au  Thanks.

[Altera_Forum]

Hi, I sent both of you an email, if you don't receive it let me know.

[Altera_Forum]

Hi, BadOmen.  

This post may be a little bit late, but I wonder if it would be possible for you to share your test IRQ example design.  If so, could I request a copy of the example? This is my email: richacevedo(at)hotmail(dot)com  Thanks a million!