STPC Elite Timer0 (IRQ0) interrupt problem

[gary239955_st]

Posted on September 15, 2005 at 12:57

STPC Elite Timer0 (IRQ0) interrupt problem

[gary239955_st]

Posted on September 14, 2005 at 18:46

We are running the Ardence\PharLap ETS 10.1 Operating System on a custom STPC Elite CPU board with a custom General Software BIOS. It's been working great for a couple of years. New software features to our application have been ongoing. Recently, however, we've run into a problem. The unit resets (or locks up with hardware watchdog disabled) after about 6 - 12 hours of operation.

After setting up an NMI pushbutton on the SERR# pin to re-gain control of the device using our Visual Studio debugging sytem, the system is usually somewhere in a very low priority IDLE thread with NO interrupts occuring. After examining the 8259 Programmable Interrupt Controller registers, I found interrupt input IRQ0 (the Timer) In-Service bit is set in the In-Service Register and there is another IRQ0 (Timer) interrupt pending. Most of the time there are other interrupts pending (as one might expect). This is indicating to me that the specific EOI command to the 8259 PIC for IRQ0 was somehow missed and so now all interrupts (including the Timer - IRQ0) are locked out. I am able to get the system running again by issuing an IRQ0-specific EOI command in my IDLE LOOP thread. The PharLap Timer(IRQ0) ISR is very straight forward and there appears to be no way for it to terminate prematurely without issuing an IRQ0-specific EOI. I am running a test whereby I am reading the 8259 In-Service register (after disabling 486 interrupts) in the IDLE LOOP thread and halting on the IRQ0 ISR bit being set. The system stops almost immediately. From reading the 8259 PIC documentation, I am under the impression that the only way for the IRQ0 In-Serivce (ISR) bit to be set is if the 486 responded to the 8259 INT pulse with an INTA pulse. This means the 486 is in the process of obtaining the interrupt vector and branching to the interrupt routine. So as long as I disable interrupts while reading the 8259 status registers in the mainline IDLE LOOP thread, I shouldn't actually see any ISR bits assuming they get cleared properly in the interrupt service routines. Is this reasoning correct or am I missing something here? Is there specific documentation for the STPC Elite Interrupt Controller or is the Intel 8259A documentation sufficient? I know there is an ERRATA posted that the Interrupt Controller mask bits don’t get cleared during the ICW1 write. Could this be a timing issue since the IPC is hanging off of the ISA bus? Thanks in advance for any help on this problem.

[kaouther]

Posted on September 15, 2005 at 12:29

The documentation of Intel 8259A interrupt controller is the right one. No specific documenataion for the STPC Elite Interrupt Controller.

IF there is another interrupt pending it could be due to the issue in the errata sheet. ''CLI instructions must be issued prior to programming ICW1.'' in order to avoid interrupt. It is mentioned in your mail that you are able '' to get the system running again by issuing an IRQ0-specific EOI command in my IDLE LOOP thread. '' Deos this solve the problem?

[gary239955_st]

Posted on September 15, 2005 at 12:57

Thanks for the quick reply.

That fact that there is another Timer0 (IRQ0) interrupt pending is expected since this signal is basic on a periodic pulse that always runs. Our problem is that it appears the Timer0 (IRQ0) In-Service bit isn't getting cleared and so Timer0 (IRQ0) interrupts are ''halted''. And since the Timer0 (IRQ0) interrupt is highest priority it prevents all other interrupts from running. The errata topic refers to the ICW1 register which is usually set up once during boot time. It is just referring to the fact that the mask register which normally gets cleared automatically with a write to ICW1 in the Intel 8259A doesn't get cleared STPC. The workaround is to disable 486 interrupts globally with a cli() so the programmer can then manually clear the 8259A mask register after writing ICW1.