Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
21 years ago

Nios stops responding to interrupts

Using Nios(3.2), Nios32@30mhz with some user logic modules in the C4. The simplest possible ISR will works a random number of times (< 30) and then stop working. The IRQ signal from the user logic is still low, but the ISR stops getting called just as if the IRQ is being masked in the Nios core. I have stripped down the ISR to just:

int main(void)

{

....

nr_installuserisr(na_myisr_irq, myISR, 0);

count = 0;

nr_setirqenable(1);

....

}

//ISR

static int count;

void myISR(int context)

{

printf("count %d\r", ++count);

return;

}

This code should execute indefinitely, yet it locks after a random number of times. I have added sw delays in both the main routine and the ISR, but it does not fix the lockup. Using a push button or a signal generator as an interrupt source, I can see that the rate of interrupts makes no difference either. The non-deterministic nature of the problem suggests timing/floating input type behavior, yet the timing report says all constraints are met by wide margins. Altera support say they have verified the problem, and are are looking into the cause.

If this really is a generic Nios problem, I can&#39;t be the first person to run into it. Anyone else see this?

8 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    21 years ago

    This is because printf uses the timer irq and because your isr never clears it&#39;s irq&#39;s bit. Every time your irq returns the isr manager is going to service the next irq which is just a big switch statement, so your irq can and will lock up everything else.

    If you really don&#39;t want to service your irq then you can change the priority of the timer irq and avoid this problem in most cases, but I fully recommend servicing your irqs.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    21 years ago

    My example was stripped down to isolate the behavior. My real code does clear the interrupt condition inside the ISR, and it does exhibit the masking behavior whether I use printf or not.

    I thought that the system ISRs (spurious, CWP overflow, etc) all used high priority IRQ#s below 16. All my user ISR#s are above these and above the uart IRQ#s, and so should not be blocked. Do you mean that I have to do a nr_setirqenable(1); inside my user ISR to allow even higher priority ISRs?

    Where do I look to see the IRQ# for this timer?

    Thanks
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    21 years ago

    --- Quote Start ---

    originally posted by tns1@Jul 16 2004, 06:11 PM

    where do i look to see the irq# for this timer?

    --- Quote End ---

    It should be in the SOPC builder window as well as the "excalibur.h" or "system.h" file that SOPC Builder generates.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    21 years ago

    (Another duplicate. Too bad this forum doesn&#39;t have a delete-post option.)

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    21 years ago

    No timer at all in SOPC &#39;system contents&#39; or in excalibur.h. If its there, it looks like it is not accessible from the GUI. Are we talking about a baud rate reload timer? I do see that each of my 4 serial ports has an IRQ#. Since these are all of higher priority than the ISR I am testing, changing their priority wouldn&#39;t fix anything. On the other hand, if I misunderstood and need to explicitly reenable interrupts inside my ISR for any ISR to work, then that explains why it would lock, it just does not explain why it locks only after a seemingly random# of interations.

  • Int3lSystemsLearning's avatar
    Int3lSystemsLearning
    Icon for New Contributor rankNew Contributor
    2 years ago

    I'm also encountering this issue and don't know where to continue. Been working with Nios II economy over the summer to advance my FPGA SoC skills for University, but am stumped by this bug.

    The biggest issue is that the system refuses to lock up in debug mode or while connected to console, so I feel like I'm solving this blind.

    Around 30s the system seems to lock.

    After 30s it will lock instantly if I disconnect the debugger or console.

    Is this intentional from Intel?(I don't have a license beyond installing Quartus 18.1 lite and using Nios ii economy)

    Being only available while connected to the console is fine for learning.

    Any information would help.

    ***********This is not a graded assignment or for production*************

    • amarkh's avatar
      amarkh
      Icon for New Contributor rankNew Contributor
      2 years ago

      Did you ever find the solution to this problem? I have a very similar problem where the irq works fine in console after running as hardware but runs into problems when I stop or if I flash the .elf with the .sof

  • amarkh's avatar
    amarkh
    Icon for New Contributor rankNew Contributor
    2 years ago

    I was actually able to solve my problem. I was using the printf() function inside of my code which is controlled by the JTAG connection, so as soon I unplugged the connection my code would break because the STDIO library couldn't be used without JTAG. After changing my code around to just toggle an output pin and scoping it, it never broke even with the interrupts.