1. Home
  2. Field-Programmable Gate Arrays
  3. Nios stops responding to interrupts

Nios stops responding to interrupts

QuartusII 4.0 SP1, SOPC builder with Nios 3.2, Cyclone C4.

I have the Nios32 @ 30mhz working fine with my user logic modules, but any ISR I try works a random number of times (1 to 30 times?) and then stops getting called. By bringing out some internal signals to pins, I can see that the irq signal from my module is asserted, but the ISR just does not get called. This is the first time I have tried using Nios interrupts, but I am getting it straight from the examples.

As a test, I wrote an ISR that just increments and prints a count value, and does not clear the interrupt. There is no foreground code other than installing the vector and enabling interrupts. I would expect my ISR to get called indefinitely, (context save, execute, context restore), but it just works a random # of times and stops.

This is the only handler I have installed, but I know the spurious handler is installed by default (it works), as well as the CWP handler (dont know if it works - how to test?). The behavior suggests stack/memory corruption from the context save/restore. I don't re-enable interrupts in my ISR, so I don't expect nested interrupts.

I have seen weird behaviors whenever the systhesis does not match the assembled libraries used to compile (forgot to use 'Generate'), but I have triple-checked. Any ideas/new errata?

Reply to
tns1
Loading thread data ...

Hello,

I have seen similar behaviour. What I found is that if the main loop is very tight, the interrupt handler will not get called ... very bizarre.

ie: if I have a main loop of:

while (1); // loop infinitely, waiting for a HW interrupt

... the ISR does not get called. However:

while (1) printf( "." ); // loop, printing a dot each time around

... allows the ISR to be called. IIRC, even doing a small delay causes the ISR not to be called, until the delay is sufficiently large. ie:

while (1) for (i=0; i QuartusII 4.0 SP1, SOPC builder with Nios 3.2, Cyclone C4.

Reply to
Peter Sommerfeld

Yes I remember now that how often the ISR was reliably called was inversely proportional to how tight my main loop was ... ie, sometimes I would see sporadic interrupt trapping like you are.

-- Pete

Reply to
Peter Sommerfeld

I have an 8ms delay in my main loop now, and I still have the problem so it does not seem like the same one. I can try adding more code to my loop. Still, neither the behavior you describe nor the one I am seeing are correct so what's the root cause?

My user logic module clears the IRQ whenever I read a register. Normally this is done in the ISR. Eventually the IRQ does not clear because the ISR is not called. (This does not seem to be the case of the ISR getting called, but not clearing the IRQ for some reason). I tried adding a read of the same clearing register in my main loop every 100ms. This 'kick starts' the Nios when it is ignoring IRQs, but probably at a cost of a lost IRQ - it works, but is not acceptable.

I can also exit my main loop (via a terminal key press), and perform a manual read of the clearing register. This does clear the asserted IRQ signal, but does NOT restore the system to normal operation. Even though main line code runs OK, subsequent IRQs are still ignored. The only way to re-enable interrupts is to reset everything. This really sounds like an IRQ is being blocked in the Nios core kinda like interrupts were never re-enabled internally during the previous context restore (or vector table corruption or...). I guess I need to try the debugger so I can look at stack pointers, status registers, etc.

I read about an option on the CWP manager that selects between HW & SW handling of overflows on the register window but I don't see this choice on any tool dialog.

Peter Sommerfeld wrote:

Reply to
tns1

I don't know anything about Nios.

You might try talking to software geeks. There is a classic interrupt bug where the IRS turns off the interrupt but forgets to make one last check to see if an interrupt came in just before it turned it off.

You should be able to debug this with a little work. Do you have a LED on your IRQ signal? Is it on or off? If it's on, then the software is not processing it. If it's off... Keep dividing the search.

Bugs that happen often/easily are easy to fix. The hard ones are the ones that only happen when you aren't looking or once per week or month.

--
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.
Reply to
Hal Murray

Have you read the STATUS reg? You can read it with a RDCTL %g7 instruction. Bit 15 of the reg is the interrupt enable and 9..14 are the current interrupt priority. If these aren't what they should be (ie. IE is 0, IPRI is I have an 8ms delay in my main loop now, and I still have the problem so

Reply to
Peter Sommerfeld

Thanks for the tip. Right now my code is all C, but I have hopes of getting GDB working tomorrow - should answer many questions. One thing that I did find is that delays in either the ISR or the main loop did not help. Since the problem behavior masks interrupts, I forced an interruptenableblah() but it did not fix things. Odd, I believe the debug port uart uses interrupts and it never stops working.

I looked for vector table corruption and noticed that all the vectors, including my installed ones, point to addresses in flash. My system is supposed to copy the flash code to sram and execute from there. This does not seem correct unless all IRQs are first directed thru a trapping routine like I have seen for some RTOSes. The debugger should tell all.

Peter Sommerfeld wrote:

Reply to
tns1

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.