68332 horrible crash

You get a "spurious interrupt" if an IRQ is signalled but then cleared before the processor has entered the corresponding interrupt routine. This can happen if the interrupt is signalled for a very short time, especially if you have interrupts disabled for at the time. But there should not be a problem if the firmware responds to an interrupt by telling the FPGA to disable future interrupts.

Perhaps the FPGA code has a bug allowing glitches on the interrupt pin when the interrupts are disabled?

You could also add a spurious interrupt handler consisting of a single "rte", but that seems a little inelegant.

mvh.,

David

Thanks. My FPGA guy doesn't think he's making glitches, but it sure seems like he is.

Sounds like the 68K folks copied the PDP-11 interrupt system, which had a similar "feature" as regards glitch interrupts.

I'm an engineer, so I don't mind inelegant.

John

When you say "shut down the associated subsystem" do you mean power down a chip that is still driven by another chip that is powered up?

If so then this might not be a software bug.

John Eaton

Ok, but in this day and age such a "feature" would surely be a candidate for an entry on the errata sheet.

We all need our kludges :-)

--
Regards, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.

Not perfectly reliable, but how about having him put in an interrupt count register, that internally increments from the signal driving that output pin? Then you can ask the FPGA how many interrupts it thinks it's generated (make the register not be cleared by whatever startup procedure you have for the micro, so that it will survive crash & reset)

Common causes of FPGA's doing odd things is having an asynchronous input affect more than one thing in the logic, as each part of the fpga may see it through a different time delay or even collection of analog issues. The only thing an external input should really be feeding is an input register - everything else should be based on the registered value, not the raw input.

And that output had better be registered too - if it's a combinatorial result its likely to glitch.

I read it as the CPU crashing not the FPGA, but the likely cause is the same,- a glitch that reaches some logic and not other inside the CPU sending it to lala land.

some MCU's latch the interrupt even when you configure it as level triggered, avoiding problem. but it means you have to aknowledge the interrupt twice, in the periperal and in the cpu.

guess you could get kinda the same functionality, by -if possible- configuring the interrupt as edge triggered and making the fpga "wiggle" the pin as long as it has an active interrupt.

just found this:

te/M68331_332TUT.pdf

5.2.6 Problem: The Processor Takes a Spurious Interrupt Exception ...

1. There are noise spikes on an IRQ line. Use pull-up resistors on the IRQ lines.
2. A square wave is used to generate external interrupts, and the source of the interrupt is going away before the interrupt is acknowledged. ... An interrupt request signal must remain asserted from the time it first occurs until the end of the IACK cycle.

-Lasse

If that were the case the CPU is very badly designed. My idea was that such a flaw in the design of the FPGA (user configuration) could get it into unanticipated states and produce glitches/unintended transitions on the interrupt line to the processor.

No, what I mean is that, when a particular interrupt-driven scan function isn't running, it seemed logical to disable interrupts. It's basically a device driver that runs in bursts. When it's done, I was turning off the FPGA hardware that generates the IRQ signal. It looks like doing that may create a brief glitch on the IRQ6 signal going into the CPU. But more generally, it's dangrous to disable the interrupt logic in the FPGA if that might happen when IRQ6 is asserted; the 68332 gets upset if you assert an interrupt and then remove it. Only the ISR is allowed to cause the external irq request line to go false.

So what I'm doing now is to set a state flag to "done" and, if the ISR gets fired off but the flag is set, it just clears the irq hardware in the fpga and exits. So any extra interrupt requests that happen after we have finished the i/o sequence are allowed to interrupt, but are ignored.

There are probably other ways to fix this.

Small price to pay for having level-sensitive interrupts.

John

Of course this is not the case, and your counter suggestion was quite appropriate and practical. The CPU32 has been around for almost 2 decades now, and the spurious interrupt vector has predated it by another decade or so on the 68000. It was just that John was hit by a spurious interrupt and the vector had not been setup at all - normally such interrupts do not occur so he has not have had to deal with them. Davids suggestion to just do a RTE in the spurious IRQ handler was something apparently not only I have been doing routinely for ages, it may be ugly but it works OK if the glitches are not too many (and if they are they cannot remain unnoticed). I would guess John has set the handler to a RTE and forgotten about the issue by now :-) . And even if there are no glitches setting the spurious IRQ to a RTE is a good practice, having a single glitch per year on a well designed system is quite unlikely, but not that unthinkable anyway.

Dimiter

------------------------------------------------------ Dimiter Popoff Transgalactic Instruments

------------------------------------------------------

When you say "turning off," do you mean, as in removing power?? Surely _THAT_'s not a Good Idea. More probably you mean just de-asserting an enable signal, right?

I'm down with the idea that your FPGA guy _IS_ doing something wrong. It's reasonably clear that if he just and's the IRQ request line with the enable line, it leaves the door open for glitches of all kinds. A better approach is to latch the IRQ request, and let the and-gate just drive the latch input.

Jack

It looks