Re: Problem Implementing Multiplexed GPIO Interrupts in XScale
From: Mark Murawski (mmurawski_at_NO.vocollect.SPAM.com)
Date: 04/06/04
- Next message: Xu Jun: "Re: Struct Alignment for ARM CPU"
- Previous message: Michael: "PlaySound LNK2019"
- Messages sorted by: [ date ] [ thread ]
Date: Tue, 6 Apr 2004 10:25:04 -0400
I'm not sure if anyone is still even looking at this thread, but I think I
have a better understanding of the problem I'm running into. I've learned a
lot about level vs. edge triggered interrupts. While I think level
interrupts would drastically help my situation, I think a real root cause is
that I'm actually disabling my edge detect registers for the duration of the
execution of my IST. The problem arises when another edge does occur during
the execution of my IST, but it doesn't register as an interrupt because the
edge detect has been disabled. When I re-enable the edge detect in
OEMInterruptDone, it doesn't detect an edge. (I'm getting ahead of
myself...)
Here's my sequence of events that are bad...
OEMInterruptEnable:
- I set the rising edge detect register for my GPIO in question. I also
unmask the single interrupt source for all of the multiplexed GPIOs. (If
necessary.)
OEMInterruptHandler (The Real ISR):
- I detect that an interrupt has occurred on the multiplexed GPIOs. I
look at the edge detect register and determine which GPIO caused the
interrupt. I then (here's the bad thing) clear the rising edge detect
register for this GPIO. I do this because I don't want just this GPIO to
cause any more interrupts until the IST has called OEMInterruptDone. I then
clear the edge detect, and return the proper SYSINTR value.
My IST:
- I do my stuff. In this case, let's say it's my KITL ethernet handling.
The interrupt source will end up going away because I service everything.
HARDWARE:
- While my IST is doing stuff, and before it has had a chance to call
OEMInterruptDone, my hardware will cause another interrupt, which will cause
my GPIO to rise. Unfortunately, my edge detect register is still cleared,
so no edge detect transition is seen.
OEMInterruptDone:
- Finally, my IST calls OEMInterrupt Done. Here' the rising edge register
for my specific GPIO is set again, which should allow more interrupts to be
seen. Unfortunately, the edge I'm missing has already happened. I will not
get another interrupt.
Does this make sense?
So, what I'm currently trying to do is come up with some way to look in the
OEMInterruptDone to see if the interrupt is already asserted. It would be
great if it was really a level triggered interrupt, 'cause my problem would
be solved, but it isn't. I'd like to find some way in OEMInterruptDone to
trigger another interrupt. I've thought about using a very short timer, but
it's a bit sloppy.
Anyone have any ideas? Has anyone really implemented a rock solid ISR/IST
model on the XScale to use multiplexed GPIOs as interrupt sources?
Mark
"Seung Yi" <seungyi@codetelligence_NOSPAMMERS_.com> wrote in message
news:opr5bxf8vnswt9p6@localhost...
There is one problem with the XScale edge detect implementation you may
want to look into. I believe it has a minimum low/high time of 1
microsecond or so (you'll have to look up the actual value, can't remember
it off the top of my head).
If the interrupt source is level triggered you may have problems (see
below).
The problem is that when this edge detect is used with a level triggered
interrupt source there is the potential of missing an interrupt if the
high/low time requirement is not met. A level triggered source will
assert the interrupt line until it is serviced, but lets say that while
processing the interrupt (which clears it) the peripheral gets more data,
for a brief period it may de-assert the interrupt and then quickly go back
to an asserted state (level triggered sources are allowed to do that).
This transition may be very short and the GPIO circuit will not detect it
as a valid edge. Normally on level triggered interrupts this will simply
retrigger your IST to run again, but since you are running with an edge
detect circuit, the interrupt will be missed. One way to check this is to
probe your interrupt line and see if it is asserted, if so, the GPIO
circuit did not detect the edge.
On Mon, 22 Mar 2004 18:57:59 -0500, Mark Murawski
<mmurawski@NO.vocollect.SPAM.com> wrote:
> Hey guys. I'm having a bit of a problem. (Of course!) I'm trying to
> implement the OAL pieces for some hardware interrupts in my new XScale
> based
> platform for some GPIO's above GPIO's 0 and 1. These are all of the
> GPIO's
> that are multiplexed to a single first level interrupt source. I haven't
> found any good examples of this being done in any BSPs, and I was hoping
> someone could help me out.
>
> So, here's a summary of what I'm trying to do for one specific interrupt.
> This one specific interrupt just happens to be the interrupt from my KITL
> ethernet interface. (I do have KITL working in polling mode, but I'm
> using
> it as my first GPIO interrupt guinea pig.)
>
> At OEMInit, we unmask the GPIOXX interrupt source in the ICMR. (Bit 10.)
>
> In our OEMInterruptEnable function for each interrupt source, we set the
> proper bit on the GPIO Falling Edge Detect Register..
>
> In our ISR, we read the ICHP to determine what our interrupt source is.
> When
> it's the GPIO source, we then read our GPIO Edge Detect Registers to
> determine the actual source.
>
> When our interrupt of interest shows an edge detect, we clear the edge
> detect register by writing a 1 to the bit, and then we clear the falling
> edge detect register to effectively "mask" this single GPIO interrupt
> source
> for the length of the Windows CE IST. We only want to mask the single
> interrupt source to avoid masking all GPIO interrupts. This is a "bad
> thing"
> in CE, right?
>
> Then, in our OEMInterruptDone routine, for this interrupt, we re-set the
> proper falling edge detect register to effectively "unmask" just this
> GPIO
> interrupt source.
>
> Now, here's our problem. We see interrupts work properly for a short
> period
> of time. But then things quickly fail, and we stop getting interrupts.
>
> We have tried an alternate implementation, where ALL GPIOXX interrupts
> are
> masked off for the duration of our IST, and this actually seems to work
> much
> longer. However, this is not an acceptable long-term solution because of
> the
> multiple time-critical interrupt sources on GPIOs.
>
> Is there an example of what, exactly, we should be doing to use higher
> number GPIOs as interrupt sources? Am I missing something obvious? Is
> anyone else doing this reliably?
>
> Thanks in advance for any help.
>
>
> Mark Murawski
> Vocollect, Inc.
>
>
>
>
-- Seung Yi Chief Technologist Codetelligence, Inc. Web : www.codetelligence.com
- Next message: Xu Jun: "Re: Struct Alignment for ARM CPU"
- Previous message: Michael: "PlaySound LNK2019"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
