[En-Nut-Discussion] Re: Re: Full Duplex operation (Damian Slee)(lost FIN packets)

[Damian Slee]

>>I am interested what 10 00 10 00 means

??  By default ethernut pulls the data line high, which seems to work
suprisingly.  So I just put a low notch where the full duplex bit would
be.
So the virtual eeprom data probably looks like FF FF BF FF, which would
be 11111111 11111111 10111111 11111111.  So I havent' moved from the
original design to much, and the rest of the initialisation code hasn't
changed.  It did take a little trial and error in the clock count,
reading back CONFIG3 to see when I started clearing the full duplex bit,
or led bits.  A more thorough implementation would implement all the
lines, chipselect and data out.  But the clock count seem to work for
me.

-----Original Message-----
From: Dusan Ferbas [mailto:dferbas at dfsoft.cz] 
Sent: Wednesday, 17 March 2004 10:24 PM
To: en-nut-discussion at egnite.de
Subject: [En-Nut-Discussion] Re: Re: Full Duplex operation (Damian
Slee)(lost FIN packets)

Hi,

definitely it looks like HW. We are using Charon II modules which have
93C46 assembled. We have also manageable eth. switch with Broadcom
BCM5325M (we are developing this product so I know how to configure it).

Once switch was forced to full duplex we were not able to reproduce lost
FINs. When half-duplex configuration was forced in 93C46 it also behaved
as expected.

---
We are also using UDP broadcast and answers are also broadcasted. When
there was a half/full duplex issue we had to add some random interval to
avoid collisions. Is collision detected by RTL and propagated to upper
layers so NutUdpSendTo returns non zero ?

---
There are four bytes in 93C46 + 6 bytes MAC. I know that 00 00 30 00
works in half-duplex LED LINK and CRS. Do you have some brief
explanations for these bits to save data sheet mining ? (I am interested
what 10 00 10 00 means).

------------------------
>Here is my code, which is setting half duplex for me.  Using the EESK 
>pin 79 out of realtek to input pin on mega128.  output pin from mega 
>128 to pin77 on realtek.
>
>Have only tested it on one unit.  It counts clocks, and sets the output

>low where the fullduplex bit from the 9346 eeprom should be, to disable

>it.  Then sets it high again to act the same as before for the 
>remaining bits (LED's etc).
>
>This is the modified from the new driver.
>To verify, there is a commented fdup = nic_read(NIC_PG3_CONFIG3);, 
>which I was displaying later.  Should be 0x30, for half duplex, LEDS1&0
on.
>
>I still get Tx packet loss, but less than before. Let me know your 
>results.

Dusan

_______________________________________________
En-Nut-Discussion mailing list
En-Nut-Discussion at egnite.de
http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion