PIC + IRQ + EOI ... and it hangs ... but why ??

Index > OS Construction > PIC + IRQ + EOI ... and it hangs ... but why ??

Author

Thread

DOS386

Joined: 08 Dec 2006
Posts: 1901

DOS386

When I brew an "exclusive" ISR (not chaining to BIOS or other "previous" stuff), I must send EOI , (2 EOI's for the "slave" PIC ???) otherwise the PC hangs. Shocked

But what does the EOI actually do and why does it hang otherwise ? It is relevant at what time / place inside the ISR the EOI is executed (seems to be "usually" at the end) ? Is it evil/risky to send it more than 1 time per IRQ ? Also there are "specific" and "unspecific" EOI's and usually the "unspecific" is being used, is there any point to use the "specific" one ?

24 Feb 2009, 01:28

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 17253
Location: In your JS exploiting you and your system

revolution

IIRC EOI releases the INTR request at the hardware level and allows for the detection of the next lower priority request. If you don't release the INTR with EOI then you get stuck in a loop of servicing interrupt requests because the CPU thinks the interrupt is still active.

24 Feb 2009, 02:38

Japheth

Joined: 26 Oct 2004
Posts: 151

Japheth

revolution wrote:

If you don't release the INTR with EOI then you get stuck in a loop of servicing interrupt requests because the CPU thinks the interrupt is still active.

That's not quite correct. The EOI is intended for the PIC only. If no EOI is sent to the PIC then the PIC thinks the interrupt is still pending and the CPU will receive no further IRQs.

You can easily test what's going on in the PIC by reading its IRR (interrupt request register) and ISR (interrupt service register). After EOI is sent to the PIC, the bit in the ISR of the currently handled IRQ will change.

26 Feb 2009, 19:21

bitRAKE

Joined: 21 Jul 2003
Posts: 2906
Location: [RSP+8*5]

bitRAKE

It has been a long time since I read the docs, but isn't there some way to set the triggering to where the PIC assumes the IRQ will be handled? I thought there was four triggering modes, but one that is used by most everyone.

27 Feb 2009, 16:47

DOS386

Joined: 08 Dec 2006
Posts: 1901

DOS386

Japheth wrote:

That's not quite correct. The EOI is intended for the PIC only. If no EOI is sent to the PIC then the PIC thinks the interrupt is still pending and the CPU will receive no further IRQs.

Thanks. CPU will receive no further what exactly ? IRQ's of same type ? Of lower priority ? Any IRQ at all ?

28 Feb 2009, 12:36

bitRAKE

Joined: 21 Jul 2003
Posts: 2906
Location: [RSP+8*5]

bitRAKE

It would be same type or higher priority, iirc.

28 Feb 2009, 15:35

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 17253
Location: In your JS exploiting you and your system

revolution

DOS386 wrote:

Japheth wrote:
That's not quite correct. The EOI is intended for the PIC only. If no EOI is sent to the PIC then the PIC thinks the interrupt is still pending and the CPU will receive no further IRQs.

Thanks. CPU will receive no further what exactly ? IRQ's of same type ? Of lower priority ? Any IRQ at all ?

There do exist documents for the PIC chip Shocked

Have you tried my webpage yet?

28 Feb 2009, 15:39

bitRAKE

Joined: 21 Jul 2003
Posts: 2906
Location: [RSP+8*5]

bitRAKE

I miss read Japheth's reply:

If no EOI is sent then only higher priority IRQ's can be sent by the PIC - same and lower priority IRQ's will be blocked.

01 Mar 2009, 02:18

< Last Thread | Next Thread >

Forum Rules:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum