I have a small test program where the only interrupt I've enabled is the periodic interval timer, and it's been configured to generate 1-msec interrupts.
The system peripheral interrupt service routine...
1) toggles an I/O pin to show it's been serviced 2) if the PIT interrupt is active, then 2a) reads the PIVR register to clear the interrupt, 2b) toggles a (2nd) different I/O pin
The main loop toggles a (3rd) different I/O pin.
------------------------------------------------------
The problems are:
A) Even though the I/O pin associated with the periodic interval timer (PIT) is toggling every 1-msec like it should, the other I/O pin in the system peripheral interrupt service routine that shows when the system peripheral ISR has been serviced toggles virtually continuosly (every 4 or 5 usec's with a 25 MHz MCK).
B) The 3rd I/O pin that's supposed to toggle forever in the main loop never toggles.
I've tried trapping all the system peripheral interrupt sources I can find documented in the datasheet, but none of them (other than the PIT) appear to be active.
Question 1 = Can anyone point me to a place in the AT91SAM7S datasheet that clearly defines what all the system peripheral interrupt sources are? I ask this because of the datasheet text that says things like "the system peripheral interrupts, such as the periodic interval timer, debug UART, etc.". It's the "etc." that's throwing me off. I've been unable to locate any definitive text in the datasheet that says "these are all the possible sources of system peripheral interrupts".
Question 2 = Are there any system peripheral interrupts that are enabled by default, i.e., by the generic SAM7.s code generated by the KEIL tools when a new project is generated?
Question 3 = Can anyone tell me how to clear *all* possible sources of system peripheral interrupts (before globally enabling interrupts), so that I can make sure the only one that's been enabled is the single PIT interrupt that I explicitly enabled?
Thanks, Dave.
Okay... problem solved. Sorry to have to admit it was due to cockpit error.
Problem was caused when, somehow, as I cut/pasted/hacked code from a working SAM7S32 based project to my SAM7S256 based project I inadvertently changed the type of system peripheral interrupt from "HIGH LEVEL" to "POSITIVE EDGE". Not sure of all the ramifications, but when I changed it back to "HIGH LEVEL" my bad symptoms went away.
I'm not exactly sure how the interrupt H/W in the chip works, but my current best guess is that when the system peripheral interrupt was entered (when configured for "POSITIVE EDGE"), it registered that the interrupting condition was still active and generated another pending interrupt. So... when the ISR was exited, the INT was already pending again (even though the source of the interrupt was not), and the system entered a sort of catch-22 infinite loop.
If this is how the chip works, that seems pretty odd to me. Of course, that's only my opinion. The bottom line is I've got to study the datasheet much closer to see exactly how the different interrupt modes work, to figure out how my code got so lost in this infinite loop with the system peripheral interrupt in the first place.
Sigh... life goes on.
Dave.