Greetings:
I don't expect that current readers of this newsgroup will have direct experience with this issue but I could be surprised :-) I will appreciate related answers in any case.
I have a problem with software timer interrupt status on the i8096; 's/w timer 0' interrupts are replaced by 'timer1 overflow' interrupts (as determined by the status in IOS1) on average between 7 and 15 percent of the time in the programs I'm debugging. (I've instrumented the code with counters). No where in the code is 'timer1 overflow' interrupt enabled (INT_MASK bit 0) and software timer interrupt is enabled (INT_MASK bit 5). 'timer1' is a free-running counter mod 16 bit and cycles in ~131 msec; 'software timers' are based on this timer and implemented in the mcu in hardware using a content-addressable memory addressed by timer values. The anomaly makes an accurate system tick ISR difficult to reliably implement; the system timer code uses software timer 0 (one out of four) and the tick ISR must also process software timer 1 -> 3 interrupts. For now I distinguish between the vague software timer 0/timer1 overflow interrupt condition and interrupts from the other software timers and consider the first condition to merit a tick increment. This is non-deterministic since some of the interrupts are actually bogus timer1 overflows but if I ignore those, I miss (drop) real timer 0 interrupts and the timer code fails (the bogus interrupts are nearly simultaneous with real timer 0 interrupts and reading the status register IOS1 to see the timer1 overflow status clears the real but invisible timer 0 interrupt status so it is never processed).
No datasheet in my possession discusses this issue. I do not have other targets for testing in case it is a component failure or issue with the ICE.
If anyone has encountered a similar problem on this arch or any other I'd be thankful for some insight. (please direct flames regarding age of the arch or my priorities to /dev/null).
Regards,
Michael