John Larkin wrote:> On Mon, 09 Mar 2009 21:03:32 -0700, John Eaton <nospam@spam.com> > wrote: > >> John Larkin wrote: >>> Situation: an FPGA drives the IRQ6 input, the portF pin. It's set up >>> to use another chip select as the autovector generator. This mostly >>> works. The FPGA pulls it low, the ISR runs, and the ISR pokes the FPGA >>> to release (raise) the interrupt request pin before it exits. >>> >>> But sometimes the firmware wants to shut down the associated subsystem >>> so tells the fpga to clear the interrupt request, which de-asserts >>> (pulls high) the port F pin. Then the cpu traps with a "spurious >>> interrupt" error and *everything* is trashed. It takes a full >>> powerdown/powerup to recover. >>> >>> I can fix this by never disabling the interrupt signal from the fpga, >>> and ignoring any unwanted interrupts in the isr. But it's curious. >>> Seems like requesting the interrupt, then changing your mind, is >>> really a bad thing to do. >>> >>> 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 > > 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.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> 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 >
68332 horrible crash
Started by ●March 9, 2009
Reply by ●March 12, 20092009-03-12