Re: CS8900A EthDrv by Karel
Karel
Wed Feb 02 12:04:10 CST 2005
I will connect two threads.
First, I check documentation (I download one from web, dated MAR'99 and it
has at bottom DS271PP3). Code follows 5.7.6 procedure to send packet. In
theory we can check TX Underrun. I will try to find if there is chance to
get this state. It is question of settings when packet transmit is enabled.
I check code and we start transmit when full packet is written to chip
buffer. So in theory Tx Underrun should never occur. Another item - send
isn't interrupt driven. It is always in pool mode.
I would expect there is some magic problem with interrupt. From my
experience it isn't always related to KITL at all. If you have some LEDs on
your board I suggest instrument your interrupt handler to indicate interrupt
on one LED, then timer interrupt on other (e.g. switch LED each 1000
interrupts) and last one for KITL related interrupt. KITL thread runs on
some priority level (I forget exact value, it is about 118) - if there is
looping interrupt on higher priority, you will never get interrupt. However
if KITL works in pool mode....
We can take it off-line. Simply send me mail (remove online from my
address).
--
Karel Danihelka
---
Windows CE CoreOS
This posting is provided "AS IS" with no warranties, and confers no rights.
---
"voidcoder" <voidcoder@yahoo.com> wrote in message
news:OmJplUHCFHA.208@TK2MSFTNGP12.phx.gbl...
> Hi Karel,
>
> Could You please tell me if You are using CS8900A with interrupt
> driven KITL, or in polling mode? It works perfect for me when
> using polling mode (OAL_KITL_FLAGS_POLL), but I have a couple
> of problems when using interrupts. Sometimes KITL stops replying to
> host. I guess because sometimes I miss Rx interrupts and sometimes
> because of TxUnderruns :(
> I turned on buffer events in CS8900A and I can see that
> sometimes I get RxMiss and TxUnderrun events.
>
> Absolutely no idea how it happens. I use PXA270 CPU
> and interrupt is connected to GPIO0. So, there are no
> problems connected with GPIO2_XXX range interrupts.
> I clear edge detect status and mask interrupt in the
> OEMInterruptHandler and then unmask in the OEMInterruptDone.
> It seems that it is not possible to miss interrupts in this case,
> but it happening. Even if next ethernet intterupt will be generated
> while KITL is processing previous one, even in this case
> I should receive interrupt once interrupt was unmasked
> in the OEMInterruptDone...
>
>
>
> "Karel Danihelka [MSFT]" <KarelD@online.microsoft.com> wrote in message
> news:OtSSLh8BFHA.208@TK2MSFTNGP12.phx.gbl...
>> I review code one more time and I think it is correct. We are following
>> datasheet (see 4.10.8 in CS8900A datasheet).
>>
>> --
>>
>> Karel Danihelka
>> ---
>> Windows CE CoreOS
>> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>> ---
>>
>> "Karel Danihelka [MSFT]" <KarelD@online.microsoft.com> wrote in message
>> news:ucyBG87BFHA.3096@TK2MSFTNGP14.phx.gbl...
>> > It is used in SMDK2410 BSP, but I will review code (from first look
> there
>> > should be little more code in send as you suggest). But generally it
>> > should work (I would expect issues on heavy traffic).
>> >
>> > --
>> >
>> > Karel Danihelka
>> > ---
>> > Windows CE CoreOS
>> > This posting is provided "AS IS" with no warranties, and confers no
>> > rights.
>> > ---
>> >
>> > "voidcoder" <voidcoder@yahoo.com> wrote in message
>> > news:eH38OS6BFHA.1260@TK2MSFTNGP12.phx.gbl...
>> >> Hi. Did anybody try to use CS8900A stuff from the PUBLIC OAL library?
>> >> Does it really work?
>> >>
>> >> There is no previous transmit pending state cheking in the
>> >> CS8900ASendFrame
>> >> routine
>> >> as it is recommended in the CS8900A datasheet.
>> >>
>> >> Thanks.
>> >>
>> >>
>> >
>> >
>>
>>
>
>