PHY problem with a PC fixed at 10MB?

[greengene]

i'm having a problem where the MOD5282 appears to have its Ethernet lock up.
it is most readily accomplished from an old laptop that is 10MB only, i.e., not
10/100. so i was wondering if there is anything going on with autonegotiation
if it is only one-sided? i noticed that nndk2.4 has a fix for the micrel with a hang
from warm reset, so ...
i see that there are calls to force speed but was wondering if anyone has seen
anything along these lines before i start down that path.

[lgitlitz]

This problem isn't specific to NetBurner devices, you will see it with most auto-negotiation Ethernet devices trying to connect to a fixed speed and duplex device. A statically set device will not send out auto-negotiation responses to a link partner. The Auto-negotiation device will attempt to detect speed, it usually will get this correct. The problem then comes with the duplex, it cannot detect this and always selects half-duplex. If you are on a full duplex connection this will result in massive collisions and eventually a lock-up of Ethernet. You will probably get a similar lock up if you connect a laptop or some other Ethernet device, given it is in auto-negotiation mode when the PC is statically set.

There is a function in ethernet.h that can set the Ethenret PHY for static settings. Use this to match the settings to your statically configured PC:
/*
******************************************************************************

Set interface speed, duplex and negotiation maximumcapabilities

Parameters:
speed100Mbit - TRUE up to 100Mbit, else 10Mbit
fullDuplex - TRUE full duplex, FALSE half duplex only
autoNegotiate - TRUE use autonegotiation, FALSE above settings.

Return:
None

Notes:
None

******************************************************************************
*/
/* Used to Manually Configure Ethernet Speed and Duplex Settings */
void ManualEthernetConfig ( BOOL speed100Mbit, BOOL fullDuplex,
BOOL autoNegotiate );

[greengene]

thanks, larry.
i had laid out an approach to walk thru the options with calls to that/those functions
if we detected that we were at a state where we/nb-side
weren't getting e-net traffic when we thought we should be. problematic at best.

as an aside, i'm also going after this problem with gigE (other h/w on our board) but there
we have access to all of the phy regs and that makes it easier. i do see that i can get to
the mii stuff, etc., on the nb board for the 10/100 ports via the libraries but haven't gone
any deeper there yet.

so thanks much and i'll work on the manual setting.

[lgitlitz]

Some useful PHY functions can be found in the Etherprint.cpp system file:
C:\nburn\(platform)\system\etherprint.cpp
ShowPhyterMII() will dump all the registers to the serial port.
You can also use the following functions to read or write to individual PHY registers:
DWORD GetMII( BYTE mii_dev, BYTE addr )
DWORD SetMII( BYTE mii_dev, BYTE addr, WORD value )
The mii_dev should be set to the global variable "PHY_addr". We auto-detect this when Ethernet is initialized.

[greengene]

yes, i'm "repurposing" them for the gigE too. the linux mii.h file is being useful too.
for this i've got to go thru an i2c i/f to get to the phy but i'm planning on
macroing the library to be able to do it.

unknown devices on the nb rj-45 and likewise on out gigE. ain't it fun!

i always hear, isn't there a spec for that? you betcha - 802.3 clause umptysquat.
but what does that 'we're not compliant' mean? is that going to be a problem?
it's always sumpin...