I've configured an FIQ using this Freescale demo as a reference: https://community.freescale.com/docs/DOC-95578, and it runs well for a while. At some point during operation (roughly between a minute and 3 minutes), the interrupt source will appear asserted in the CPU as an IRQ, rather than an FIQ.
When I fist noticed this issue, I saw that Linux kernel would pick up the IRQ, notice that no IRQ handler was registered for the source, then disable the GPIO peripheral's interrupt. I then registered an IRQ handler for that spurious IRQ which takes note of the occurrence, clears the GPIO interrupt, and exits without disabling the GPIO interrupt configuration. After this spurious IRQ assertion, it will continue being asserted as an FIQ for some time but it will come into the processor as an IRQ again later and at seemingly random times. Also in my spurious IRQ handler, I have verified that the configuration in the GIC hasn't changed, that it is running on the correct CPU core, and by all intents and purposes it should be a FIQ assertion but it is not!
The FIQ source is a negative-edge on a 50KHz square wave signal through the GPIO 1 bank peripheral. The FIQ handler, when actually entered, exits cleanly and with plenty of time to spare ( ~ 10 us). We've seen on our oscilloscope that our interrupt source is asserting the GPIO line at a solid 50KHz, and when the source is serviced as an IRQ the time-to-enter in the ISR is unacceptably long.
The troubling thing is the FIQ operates correctly, until it is not seen as an FIQ by the target core.
Has anyone seen anything like this? Is there an errata for a configuration such as this? Why would the FIQ come in as an IRQ?
Thanks for your time.
