Hi All. Just looking for a little help ... I must be doing something silly, but for the life of me I can't figure it out. I've taken the TMR0 interrupt code from blinky, and used it as my own ISR. When I use this code in a new project, I can set a breakpoint at the start of the ISR, and I will always reach the breakpoint in the simulator. So far, so good. Yet when I run the application on real hardware, the breakpoint is never reached, i.e. the ISR is never serviced. Yet the rest of the application runs fine, as is witnessed by a continually up-counting counter in the main loop (proves that application isn't resetting, via watchdog or whatever). Also, my examination of the peripherals doesn't reveal any differences in the Interrupt and TMR0 configurations from the way they're setup in the simulator. Also, there's no evidence of resets or restarts (that I can find). Normally, I'd say there was something wrong with the interrupt code ... but Blinky as supplied by Keil works fine in the simulator and on real code. I should also add that I've already written several decent-sized apps that do not involve any interrupts, and they work identically in the simulator and on real hardware. I'm new to ARM. What am I missing?
OK, working with Keil, we discovered the source of the problem (though it took me a while to find a test case that was 100% repeatable). Basically, in projects that involve ISRs in modules other than main.c, the Debug Channel Interrupt (which is tied to the ULINK debugger) occurs. If you don't have the VIC Default Vector Address defined to be a valid __irq function (i.e. a valid ISR), then the program hangs when the abovementioned interrupt occurs. The solution was to define VICDefVectAddr to be a dummy ISR function, and now all is happy. IOW, the VIC has to be setup properly if interrupts from the Debug Channel Interrupt are to be expected. Why the problem only occurs if the user's explicitly defined ISRs are in separate modules is anybody's guess ...
The problem is not caused by ULINK (or any other JTAG debugger). It is due to a problem in the VIC (vectored interrupt controller) of the ARM Device. See also: http://www.keil.com/support/docs/2888.htm It is also documented in the current Philips User's Manuals under the topic SPURIOUS INTERRUPTS.
OK, thanks for the clarification -- I thought that the debug interface was the source of the spuriour interrupts, but as you've pointed out, this is more of an inherent VIC issue. Anyway, very glad to see that we have a fix. It's been working perfectly here for several days now ...