EtherLink behavior

[addonray]

On a 54417 board, I'm using this to try to detect LAN cable disconnection at the board:

if (!enet0.EtherLink())
{ //We lost the cable.
iprintf("EtherLink detected cable disconnect!\n");
close(fdnet);
fdnet = 0;
OSTimeDly(TICKS_PER_SECOND); //Wait 1 sec., then try to accept again
goto Accept_Wait;
}

It doesn't detect loss of the cable. I'm running this in a slightly modified version of the Simplified TCP Server example with Telnet. The interesting thing is, if I change enet0 to enet1 in the code it immediately finds the 2nd LAN cable as disconnected (that jack is not in use). Is this meant as a cable test? Or is there more to it? In the Rabbit world that I'm porting from, we had a pd_havelink() function that could tell if the cable disconnected.

I'm using V2.8.1 of the IDE.

Thanks,

Ray

[pbreed]

Debug or release version?

The link detection is very differnt between the two...

[addonray]

It's the release version, Paul.

Thanks,

Ray

[rlupish]

We are observing something very similar.
We are using NNDK Ver 2.7.5, with patch (multicast.cpp) to correctly register a FIFO queue with the desired interface.

Identical software (instantiated as two separate tasks, with different parameters for the two ports) receiving multicast broadcasts, at 239.255.xx.3 on interface 1 (eth0) and 239.255.yy.3 on interface 2 (eth1). The two networks are physically distinct. The applications use the UDPPacket object with a FIFO queue which is registered to the appropriate IP address, port and interface.

Initially, receptions from the sender on each network are received and handled just fine.

After disconnecting, then (after a 5-10 second wait) reconnecting the cable to interface 2, the application recovers just fine, and packets are received normally .
Doing the same with interface 1 results in the connection being down for the count . However, after physical reconnection, both ends of the connection can successfully "ping" each other .

The application, after detecting the loss of connection (by getting N consecutive timeouts on the packet receive), un registers the FIFO queue, then re-registers it before "listening" for the multicast messages.

It would seem that something is quite different is going on with the two interfaces. Being able to recover from network disconnections is an important requirement for us .

Ron

[dciliske]

Very important note with regards to the MOD54417: If there is an issue with the ethernet, be sure to mention whether the device is in switch mode or independent mode.

From context, Ron, I think you're in independent mode. Oh. I think this may be an issue with failing to re-register multicast addresses after a driver reset upon link reconnect. I'll look into this. Mind making a ticket for me to reference?

Ray: Are you in switched or independent mode? Do you have enet0 connected when you run your test on enet1? Do you have enet1 connected when you run your test on enet0? How long after the disconnect is this running? The driver does link change detection by polling the PHY IRQ line in the Processing Task. This means that the driver will detect a link change on either the next frame reception or after the link check timeout (2 seconds).

[dciliske]

Ron,

Yea looking into this, the issue is that when the link comes back up the FEC gets reset and all the multicast registration bits get cleared in the hardware. Running in Independent mode this can be relatively easily mitigated, as it is literally a bitfield. It's less clear with regards to switch mode.

Basically, it doesn't look like the MAC table for the switch is affected (which jives with what I think I've encountered before); to call the reference manual's discussion of the Ethernet Switch unclear would be a gross understatement. But if it is cleared, we do not currently have of re-registering the MACs in the table with what knowledge the Ethernet driver retains and forcing it to remember all the multicast addrs leads to a dark questioning place very quickly...

It seems that your workaround of reregistering the fifo (and triggering the re-registering the multicast MAC) is the best bet for now. Needless to say, this is revisiting some deep discussions we have had in the past regarding events and handling them.

-Dan