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

[Dusan Ferbas]

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