Nios I - Wrong IRQ Vector

[Altera_Forum]

I recently noticed a problem with a Nios (not Nios II) design implemented on an APEX EP20K device. At initialization, I set all entries in the interrupt vector table to point to the same routine: it displays the IRQ number and PC of the interrupted code and then runs a small debugger (this routine has been carefully tested). Later, the code installs interrupt handlers for a few specific interrupts: 26 - a Nios UART (shared with the GERMs monitor), 18 - a Nios timer (used by a RT-executive), and 25 - a Nios PIO register which includes the IRQ signals from two external octal UART chips. 

 The timer always generates interrupts at 500 Hz. The frequency of interrupts from the octal UARTs depends on the number of external devices attached (more replies, and more Rx interrupts), but should be several hundred per second (the Nios UART for GERMs and console output is idle). As I increased the number of attached devices, the unexpected IRQ handler was being invoked (just a few times a day). These are always for IRQs 19 and 27. There is no hardware (or Nios peripheral) for IRQ 27, and IRQ 19 is assigned to an unused Nios UART.  Using the debugger, I've confirmed that these spurious IRQs are not the result of executing a TRAP instruction - I've checked the code in RAM at the interrupted location using the debugger from the unexpected IRQ handler. When IRQ 19 happens, I've confirmed that the interrupt enable register of the Nios UART is still zero.   I'm wondering, could this be a problem with the Nios logic generating the IRQ vector: my symptoms are consistent with what would happen if the vector was latched just as it was transitioning from 25 to 18: I could get 18, 19, 25, 26 and 27 - just what I'm seeing (I wouldn't notice a spurious IRQ 26, since this has a handler). The spurious interrupt frequency seems to increase as I increase the frequency of interrupts from the external UARTs (via Nios PIO), exactly what I'd expect for this scenario.  Is this a known problem? Has anyone else seen anything similar. Is there a hardware (i.e. FPGA design) solution?

[Altera_Forum]

Have you synchronized the external UART interrupt lines to the NIOS clock? (the NIOS I interrupt controller doesn't do this for you).

[Altera_Forum]

The two external octal UART interrupt signals are inverted (since they are active low), then connected to two bits of a standard Nios PIO register with "irq_type=LEVEL". Is it still necessary to synchronize them with the Nios clock before bringing them to the PIO? 

 The other interrupt is from a standard Nios timer (so I would assume it is inherently synchronized). The interrupt signals from the Nios PIO and timer are presumably wired up to the processor according to the SOPC builder defaults.   I'm just writing the software, but I'll pass this suggestion on to the engineer who does the hardware design.  Thanks!

[Altera_Forum]

<div class='quotetop'>QUOTE </div> 

--- Quote Start ---  Is it still necessary to synchronize them with the Nios clock before bringing them to the PIO?[/b]  --- Quote End ---   Yes, because the signal connected to the IRQ pin on your PIO must not change within the specified setup and hold times for the interrupt controller. As the frequency of interrupts increases, so does the probability of an asynchronous input violating these setup and hold times. A single d-type flip-flop per input should cure the problem (two, to be really sure). <div class='quotetop'>QUOTE </div>  --- Quote Start ---  The other interrupt is from a standard Nios timer (so I would assume it is inherently synchronized).[/b]  --- Quote End ---   Yes, that&#39;s correct.