LAN91C111 TX intr problem

hi,
We are facing problem in LAN91C111 WinCE 4.2 driver. We are using Xscale
platform.
Once the TX interrupt bit is set in the Interrupt Status register it is not
getting cleared after Acknowledging it, so driver hangs in TX interrupt
handler.
Could Any one help us in solving this problem
Thanks in Advance.
With regards
AkM

K
Thu Jul 29 00:22:16 CDT 2004

It sound like the interrupts is missed??
because the PXA serial GPIO can only detect edge trigger interrupt but not
for the LEVEL triggered (but the behavior for 91c111 is more like level
trigger),
You might lost INTs between the gap of acking the INT and calling
InterruptDone (Re-eanable the Interrupt).

So you might modify you OEMInterruptDone OAL function to check is the GPIO
value, to see if the 91ca111 already latched the Interrupt,
if it did, try to re-generate a Interrupt to let your driver go throught.

"Akram" <akram@iwavesystems.com> ¼¶¼g©ó¶l¥ó·s»D
:#DJ66ILdEHA.1000@TK2MSFTNGP12.phx.gbl...
> hi,
> We are facing problem in LAN91C111 WinCE 4.2 driver. We are using Xscale
> platform.
> Once the TX interrupt bit is set in the Interrupt Status register it is
not
> getting cleared after Acknowledging it, so driver hangs in TX interrupt
> handler.
> Could Any one help us in solving this problem
> Thanks in Advance.
> With regards
> AkM
>
>

Akram
Thu Jul 29 03:23:56 CDT 2004

Hi Huang,
Thank You for u r quick reply.
The problem is that , once TX INT is generated it is not getting cleared.
I am acknoweldging the interrupt in TX handler, still the Status shows TX
INT bit set so TX handler is bieng called
infinitley for the 0 th packet itself.
In the OEMInterruptDone i am actually Enabling the raising Edge interrupt.
We are using GPIO 6 as interrupt. Does the wrong registry values leed to
this problem??
Could You please help me in solving this problem.
Thank You once again
With Regards
Akram
"K. S. Huang" <ks_huang@AlphaNetworks.com_remove.this> wrote in message
news:uO3zUwSdEHA.3260@TK2MSFTNGP09.phx.gbl...
> It sound like the interrupts is missed??
> because the PXA serial GPIO can only detect edge trigger interrupt but not
> for the LEVEL triggered (but the behavior for 91c111 is more like level
> trigger),
> You might lost INTs between the gap of acking the INT and calling
> InterruptDone (Re-eanable the Interrupt).
>
> So you might modify you OEMInterruptDone OAL function to check is the GPIO
> value, to see if the 91ca111 already latched the Interrupt,
> if it did, try to re-generate a Interrupt to let your driver go throught.
>
> "Akram" <akram@iwavesystems.com> ¼¶¼g©ó¶l¥ó·s»D
> :#DJ66ILdEHA.1000@TK2MSFTNGP12.phx.gbl...
> > hi,
> > We are facing problem in LAN91C111 WinCE 4.2 driver. We are using
Xscale
> > platform.
> > Once the TX interrupt bit is set in the Interrupt Status register it is
> not
> > getting cleared after Acknowledging it, so driver hangs in TX interrupt
> > handler.
> > Could Any one help us in solving this problem
> > Thanks in Advance.
> > With regards
> > AkM
> >
> >
>
>

K
Thu Jul 29 04:08:05 CDT 2004

Do you try to use Scope to probe the signal??
Is the Interrupt always park at high or low??


"Akram" <akram@iwavesystems.com> ¼¶¼g©ó¶l¥ó·s»D
:#LDbtVUdEHA.1648@TK2MSFTNGP11.phx.gbl...
> Hi Huang,
> Thank You for u r quick reply.
> The problem is that , once TX INT is generated it is not getting cleared.
> I am acknoweldging the interrupt in TX handler, still the Status shows TX
> INT bit set so TX handler is bieng called
> infinitley for the 0 th packet itself.
> In the OEMInterruptDone i am actually Enabling the raising Edge interrupt.
> We are using GPIO 6 as interrupt. Does the wrong registry values leed to
> this problem??
> Could You please help me in solving this problem.
> Thank You once again
> With Regards
> Akram
> "K. S. Huang" <ks_huang@AlphaNetworks.com_remove.this> wrote in message
> news:uO3zUwSdEHA.3260@TK2MSFTNGP09.phx.gbl...
> > It sound like the interrupts is missed??
> > because the PXA serial GPIO can only detect edge trigger interrupt but
not
> > for the LEVEL triggered (but the behavior for 91c111 is more like level
> > trigger),
> > You might lost INTs between the gap of acking the INT and calling
> > InterruptDone (Re-eanable the Interrupt).
> >
> > So you might modify you OEMInterruptDone OAL function to check is the
GPIO
> > value, to see if the 91ca111 already latched the Interrupt,
> > if it did, try to re-generate a Interrupt to let your driver go
throught.
> >
> > "Akram" <akram@iwavesystems.com> ¼¶¼g©ó¶l¥ó·s»D
> > :#DJ66ILdEHA.1000@TK2MSFTNGP12.phx.gbl...
> > > hi,
> > > We are facing problem in LAN91C111 WinCE 4.2 driver. We are using
> Xscale
> > > platform.
> > > Once the TX interrupt bit is set in the Interrupt Status register it
is
> > not
> > > getting cleared after Acknowledging it, so driver hangs in TX
interrupt
> > > handler.
> > > Could Any one help us in solving this problem
> > > Thanks in Advance.
> > > With regards
> > > AkM
> > >
> > >
> >
> >
>
>

Akram
Thu Jul 29 04:58:50 CDT 2004

No, interrupt is not always stays at high or low , it changes according to
recv i suppose.
But my doubt is that , TX handler will be called by polling the TX INT bit
in the interrupt handler so there is
nothing to do with interrupt pin.
I have displayed the value of GEDR also it gets cleared propely.
Only thing is that TX INT is not at all getting cleared.
Thank U
Akram.
"K. S. Huang" <ks_huang@AlphaNetworks.com_remove.this> wrote in message
news:emTeQuUdEHA.720@TK2MSFTNGP11.phx.gbl...
> Do you try to use Scope to probe the signal??
> Is the Interrupt always park at high or low??
>
>
> "Akram" <akram@iwavesystems.com> ¼¶¼g©ó¶l¥ó·s»D
> :#LDbtVUdEHA.1648@TK2MSFTNGP11.phx.gbl...
> > Hi Huang,
> > Thank You for u r quick reply.
> > The problem is that , once TX INT is generated it is not getting
cleared.
> > I am acknoweldging the interrupt in TX handler, still the Status shows
TX
> > INT bit set so TX handler is bieng called
> > infinitley for the 0 th packet itself.
> > In the OEMInterruptDone i am actually Enabling the raising Edge
interrupt.
> > We are using GPIO 6 as interrupt. Does the wrong registry values leed to
> > this problem??
> > Could You please help me in solving this problem.
> > Thank You once again
> > With Regards
> > Akram
> > "K. S. Huang" <ks_huang@AlphaNetworks.com_remove.this> wrote in message
> > news:uO3zUwSdEHA.3260@TK2MSFTNGP09.phx.gbl...
> > > It sound like the interrupts is missed??
> > > because the PXA serial GPIO can only detect edge trigger interrupt but
> not
> > > for the LEVEL triggered (but the behavior for 91c111 is more like
level
> > > trigger),
> > > You might lost INTs between the gap of acking the INT and calling
> > > InterruptDone (Re-eanable the Interrupt).
> > >
> > > So you might modify you OEMInterruptDone OAL function to check is the
> GPIO
> > > value, to see if the 91ca111 already latched the Interrupt,
> > > if it did, try to re-generate a Interrupt to let your driver go
> throught.
> > >
> > > "Akram" <akram@iwavesystems.com> ¼¶¼g©ó¶l¥ó·s»D
> > > :#DJ66ILdEHA.1000@TK2MSFTNGP12.phx.gbl...
> > > > hi,
> > > > We are facing problem in LAN91C111 WinCE 4.2 driver. We are using
> > Xscale
> > > > platform.
> > > > Once the TX interrupt bit is set in the Interrupt Status register it
> is
> > > not
> > > > getting cleared after Acknowledging it, so driver hangs in TX
> interrupt
> > > > handler.
> > > > Could Any one help us in solving this problem
> > > > Thanks in Advance.
> > > > With regards
> > > > AkM
> > > >
> > > >
> > >
> > >
> >
> >
>
>

K
Thu Jul 29 05:17:45 CDT 2004

So you mean there might be some interrupt event that fired with nothing to
do??
In most NDIS driver, the TX interrupt is for a Transmit complete and/or
failed event.
Is it possible the TX bit informed some other event rather than the transmit
complete?

"Akram" <akram@iwavesystems.com> ¼¶¼g©ó¶l¥ó·s»D
:OVCafKVdEHA.3792@TK2MSFTNGP09.phx.gbl...
> No, interrupt is not always stays at high or low , it changes according to
> recv i suppose.
> But my doubt is that , TX handler will be called by polling the TX INT bit
> in the interrupt handler so there is
> nothing to do with interrupt pin.
> I have displayed the value of GEDR also it gets cleared propely.
> Only thing is that TX INT is not at all getting cleared.
> Thank U
> Akram.
> "K. S. Huang" <ks_huang@AlphaNetworks.com_remove.this> wrote in message
> news:emTeQuUdEHA.720@TK2MSFTNGP11.phx.gbl...
> > Do you try to use Scope to probe the signal??
> > Is the Interrupt always park at high or low??
> >
> >
> > "Akram" <akram@iwavesystems.com> ¼¶¼g©ó¶l¥ó·s»D
> > :#LDbtVUdEHA.1648@TK2MSFTNGP11.phx.gbl...
> > > Hi Huang,
> > > Thank You for u r quick reply.
> > > The problem is that , once TX INT is generated it is not getting
> cleared.
> > > I am acknoweldging the interrupt in TX handler, still the Status shows
> TX
> > > INT bit set so TX handler is bieng called
> > > infinitley for the 0 th packet itself.
> > > In the OEMInterruptDone i am actually Enabling the raising Edge
> interrupt.
> > > We are using GPIO 6 as interrupt. Does the wrong registry values leed
to
> > > this problem??
> > > Could You please help me in solving this problem.
> > > Thank You once again
> > > With Regards
> > > Akram
> > > "K. S. Huang" <ks_huang@AlphaNetworks.com_remove.this> wrote in
message
> > > news:uO3zUwSdEHA.3260@TK2MSFTNGP09.phx.gbl...
> > > > It sound like the interrupts is missed??
> > > > because the PXA serial GPIO can only detect edge trigger interrupt
but
> > not
> > > > for the LEVEL triggered (but the behavior for 91c111 is more like
> level
> > > > trigger),
> > > > You might lost INTs between the gap of acking the INT and calling
> > > > InterruptDone (Re-eanable the Interrupt).
> > > >
> > > > So you might modify you OEMInterruptDone OAL function to check is
the
> > GPIO
> > > > value, to see if the 91ca111 already latched the Interrupt,
> > > > if it did, try to re-generate a Interrupt to let your driver go
> > throught.
> > > >
> > > > "Akram" <akram@iwavesystems.com> ¼¶¼g©ó¶l¥ó·s»D
> > > > :#DJ66ILdEHA.1000@TK2MSFTNGP12.phx.gbl...
> > > > > hi,
> > > > > We are facing problem in LAN91C111 WinCE 4.2 driver. We are
using
> > > Xscale
> > > > > platform.
> > > > > Once the TX interrupt bit is set in the Interrupt Status register
it
> > is
> > > > not
> > > > > getting cleared after Acknowledging it, so driver hangs in TX
> > interrupt
> > > > > handler.
> > > > > Could Any one help us in solving this problem
> > > > > Thanks in Advance.
> > > > > With regards
> > > > > AkM
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>

Akram
Thu Jul 29 06:05:50 CDT 2004

TX INT bit will be set if the transmit Completed or else if the following
error condition occurs
1.TX under run
2.SQET Error
3.LOST Carrier
4. LATE Collision
5.16 Collisions.
But if the TX INT bit is set due to the error conditions the TX Success bit
should not be set.
But TX Sucess bit also will be set. And TX Sucess bit will be set only if
the last packet is transimitted
without fata errors.
So i am not getting the reason Why the TX INT bit is not getting cleared.

I am using ethreal to capture the packets still now i have not captured a
single packet from
Board.

We have written diagnostics to test the LAN91C111 chip which works fine,
Even TFTP cleint works fine
on the board without any problem.

Thank You
With Regards
Akram.
"K. S. Huang" <ks_huang@AlphaNetworks.com_remove.this> wrote in message
news:O7i7LVVdEHA.3476@tk2msftngp13.phx.gbl...
> So you mean there might be some interrupt event that fired with nothing to
> do??
> In most NDIS driver, the TX interrupt is for a Transmit complete and/or
> failed event.
> Is it possible the TX bit informed some other event rather than the
transmit
> complete?
>
> "Akram" <akram@iwavesystems.com> ¼¶¼g©ó¶l¥ó·s»D
> :OVCafKVdEHA.3792@TK2MSFTNGP09.phx.gbl...
> > No, interrupt is not always stays at high or low , it changes according
to
> > recv i suppose.
> > But my doubt is that , TX handler will be called by polling the TX INT
bit
> > in the interrupt handler so there is
> > nothing to do with interrupt pin.
> > I have displayed the value of GEDR also it gets cleared propely.
> > Only thing is that TX INT is not at all getting cleared.
> > Thank U
> > Akram.
> > "K. S. Huang" <ks_huang@AlphaNetworks.com_remove.this> wrote in message
> > news:emTeQuUdEHA.720@TK2MSFTNGP11.phx.gbl...
> > > Do you try to use Scope to probe the signal??
> > > Is the Interrupt always park at high or low??
> > >
> > >
> > > "Akram" <akram@iwavesystems.com> ¼¶¼g©ó¶l¥ó·s»D
> > > :#LDbtVUdEHA.1648@TK2MSFTNGP11.phx.gbl...
> > > > Hi Huang,
> > > > Thank You for u r quick reply.
> > > > The problem is that , once TX INT is generated it is not getting
> > cleared.
> > > > I am acknoweldging the interrupt in TX handler, still the Status
shows
> > TX
> > > > INT bit set so TX handler is bieng called
> > > > infinitley for the 0 th packet itself.
> > > > In the OEMInterruptDone i am actually Enabling the raising Edge
> > interrupt.
> > > > We are using GPIO 6 as interrupt. Does the wrong registry values
leed
> to
> > > > this problem??
> > > > Could You please help me in solving this problem.
> > > > Thank You once again
> > > > With Regards
> > > > Akram
> > > > "K. S. Huang" <ks_huang@AlphaNetworks.com_remove.this> wrote in
> message
> > > > news:uO3zUwSdEHA.3260@TK2MSFTNGP09.phx.gbl...
> > > > > It sound like the interrupts is missed??
> > > > > because the PXA serial GPIO can only detect edge trigger interrupt
> but
> > > not
> > > > > for the LEVEL triggered (but the behavior for 91c111 is more like
> > level
> > > > > trigger),
> > > > > You might lost INTs between the gap of acking the INT and calling
> > > > > InterruptDone (Re-eanable the Interrupt).
> > > > >
> > > > > So you might modify you OEMInterruptDone OAL function to check is
> the
> > > GPIO
> > > > > value, to see if the 91ca111 already latched the Interrupt,
> > > > > if it did, try to re-generate a Interrupt to let your driver go
> > > throught.
> > > > >
> > > > > "Akram" <akram@iwavesystems.com> ¼¶¼g©ó¶l¥ó·s»D
> > > > > :#DJ66ILdEHA.1000@TK2MSFTNGP12.phx.gbl...
> > > > > > hi,
> > > > > > We are facing problem in LAN91C111 WinCE 4.2 driver. We are
> using
> > > > Xscale
> > > > > > platform.
> > > > > > Once the TX interrupt bit is set in the Interrupt Status
register
> it
> > > is
> > > > > not
> > > > > > getting cleared after Acknowledging it, so driver hangs in TX
> > > interrupt
> > > > > > handler.
> > > > > > Could Any one help us in solving this problem
> > > > > > Thanks in Advance.
> > > > > > With regards
> > > > > > AkM
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>

SORCUS
Thu Jul 29 08:11:02 CDT 2004

Hi,

> Once the TX interrupt bit is set in the Interrupt Status register it is not
> getting cleared after Acknowledging it, so driver hangs in TX interrupt
> handler.

I had a similar problem. It turned out that the ISR OEMInterruptHandler
needs to mask the LAN IRQ. If this isn't done, the ISR will loop
forever. The bit is unmasked again in OEMInterruptDone.


Regards
Christoph

Akram
Tue Aug 03 00:42:29 CDT 2004

Hi SORUS,
Thank you for Your reply.

Yes Exaclty the same problem i am facing here.

LAN IRQ means the GPIO pin which we are using for generating the interrupt??
or u mean LAN TX INT bit??
We are using GPIO 6 as rising edge interrupt .
So u mean that i have to mask GPIO 6 rising edge in OEMInterruptHandler and
unmask the same in OEMInterruptDone ?? if so then i am doing it.
Or u mean that ICMR 10 which is used for GPIO interrupts i have mask and
Unmask??

Thanks in Advance.
Please help me in solving the problem
With regards
Akram
"SORCUS" <info@sorcus.com> wrote in message news:ceat01$9ds$1@online.de...
> Hi,
>
> > Once the TX interrupt bit is set in the Interrupt Status register it is
not
> > getting cleared after Acknowledging it, so driver hangs in TX interrupt
> > handler.
>
> I had a similar problem. It turned out that the ISR OEMInterruptHandler
> needs to mask the LAN IRQ. If this isn't done, the ISR will loop
> forever. The bit is unmasked again in OEMInterruptDone.
>
>
> Regards
> Christoph

Max
Tue Aug 03 05:31:40 CDT 2004

Akram schrieb:
> LAN IRQ means the GPIO pin which we are using for generating the
> interrupt?? or u mean LAN TX INT bit??
> We are using GPIO 6 as rising edge interrupt .
> So u mean that i have to mask GPIO 6 rising edge in
> OEMInterruptHandler and unmask the same in OEMInterruptDone ?? if so
> then i am doing it.
> Or u mean that ICMR 10 which is used for GPIO interrupts i have mask
> and Unmask??

We have a intermediate stage in between (i.e. a FPGA). I masked the
interrupt there. If you don't have other GPIO IRQs you could try masking
it in the ICMR. Masking it at the source i.e. LAN91C111 is probably the
better choice.


Regards
Christoph

Akram
Wed Aug 04 01:45:29 CDT 2004

hi
Thank you for the reply.
I am trying to capture the packet using ethereal but not even a single
packet is bieng transmitted from the board, and TX int bit is getting
cleared some times but not consistently.
The bit TX_SUC is not getting set that means Transmission is not happening
successfully.

But i have implemented TFTP on this platform which works fine. [polling
mode].
Could You please help me in solving this problem.

With regards
Akram

"Max Mayer" <mayer_max@web.de> wrote in message
news:cenph7$e44$1@online.de...
> Akram schrieb:
> > LAN IRQ means the GPIO pin which we are using for generating the
> > interrupt?? or u mean LAN TX INT bit??
> > We are using GPIO 6 as rising edge interrupt .
> > So u mean that i have to mask GPIO 6 rising edge in
> > OEMInterruptHandler and unmask the same in OEMInterruptDone ?? if so
> > then i am doing it.
> > Or u mean that ICMR 10 which is used for GPIO interrupts i have mask
> > and Unmask??
>
> We have a intermediate stage in between (i.e. a FPGA). I masked the
> interrupt there. If you don't have other GPIO IRQs you could try masking
> it in the ICMR. Masking it at the source i.e. LAN91C111 is probably the
> better choice.
>
>
> Regards
> Christoph

K
Wed Aug 04 02:45:49 CDT 2004

The Rx and Tx buffer in 91c111 shared the same buffer.
So itmight be possible that the whole Buffer is fully filled by Rx Packet,
so that there is always no room to Tx any packet??

"Akram" <akram@iwavesystems.com> ¼¶¼g©ó¶l¥ó·s»D
:#HjQV6eeEHA.3124@TK2MSFTNGP09.phx.gbl...
> hi
> Thank you for the reply.
> I am trying to capture the packet using ethereal but not even a single
> packet is bieng transmitted from the board, and TX int bit is getting
> cleared some times but not consistently.
> The bit TX_SUC is not getting set that means Transmission is not happening
> successfully.
>
> But i have implemented TFTP on this platform which works fine. [polling
> mode].
> Could You please help me in solving this problem.
>
> With regards
> Akram
>
> "Max Mayer" <mayer_max@web.de> wrote in message
> news:cenph7$e44$1@online.de...
> > Akram schrieb:
> > > LAN IRQ means the GPIO pin which we are using for generating the
> > > interrupt?? or u mean LAN TX INT bit??
> > > We are using GPIO 6 as rising edge interrupt .
> > > So u mean that i have to mask GPIO 6 rising edge in
> > > OEMInterruptHandler and unmask the same in OEMInterruptDone ?? if so
> > > then i am doing it.
> > > Or u mean that ICMR 10 which is used for GPIO interrupts i have mask
> > > and Unmask??
> >
> > We have a intermediate stage in between (i.e. a FPGA). I masked the
> > interrupt there. If you don't have other GPIO IRQs you could try masking
> > it in the ICMR. Masking it at the source i.e. LAN91C111 is probably the
> > better choice.
> >
> >
> > Regards
> > Christoph
>
>