• AVR Freaks

Hot!LAN8720 seems to fail while tcpip stack keeps working?

Page: < 123 > Showing page 2 of 3
Author
Frankaas
Starting Member
  • Total Posts : 48
  • Reward points : 0
  • Joined: 2018/12/12 02:02:21
  • Location: 0
  • Status: offline
Re: LAN8720 seems to fail while tcpip stack keeps working? 2019/03/13 04:10:21 (permalink)
0
Hey Rainad,
 
Once again, thank you for your help!
 
If I poll TCPIP_STACK_NetIsReady() and only start my application (udp) state machine back up if it returns true it works fine on rare occasions: the network comes back up, but sometimes it just hangs there at TCPIP_STACK_NetIsReady() (which means it does not return true). Is this the correct approach (I'm guessing no)? What could go wrong in the netdown and netup sequence?
 
Also, if I did the netdown and then up and TCPIP_STACK_NetIsReady(), should I reinit and reopen my UDP socket or are these not influenced by the netdown/netup?
 
Franka
#21
rainad
Super Member
  • Total Posts : 1209
  • Reward points : 0
  • Joined: 2009/05/01 13:39:25
  • Location: 0
  • Status: offline
Re: LAN8720 seems to fail while tcpip stack keeps working? 2019/03/13 14:26:19 (permalink)
0
Sorry, not very clear: you're saying that after Net Down and then NetUp the TCPIP_STACK_NetIsReady() never returns true?
If this is the case, can you please use the same set of parameters that you use for the NetUp in the 1st call to Stack_Initialize() and see if that works? Could be some wrong parameters. Please provide some details.
Not sure I understand exactly what the "udp state machine back up" refers to.
 
#22
Frankaas
Starting Member
  • Total Posts : 48
  • Reward points : 0
  • Joined: 2018/12/12 02:02:21
  • Location: 0
  • Status: offline
Re: LAN8720 seems to fail while tcpip stack keeps working? 2019/03/13 15:55:16 (permalink)
0
Sorry that I wasn't clear. Yes indeed, after Net Down and then NetUp the TCPIP_STACK_NetIsReady() never returns true in most cases but in rare cases it does return true and the network comes back up.
 
I use the exact same parameters with the exception of the IP-address.
 
In the first call to Stack_Initialize() I use:
/* const */ TCPIP_NETWORK_CONFIG __attribute__((unused)) TCPIP_HOSTS_CONFIGURATION[] =
{
/*** Network Configuration Index 0 ***/
    {
        TCPIP_NETWORK_DEFAULT_INTERFACE_NAME_IDX0, // interface
        TCPIP_NETWORK_DEFAULT_HOST_NAME_IDX0, // hostName
        TCPIP_NETWORK_DEFAULT_MAC_ADDR_IDX0, // macAddr
        default_client_address_idx0, // ipAddr
        TCPIP_NETWORK_DEFAULT_IP_MASK_IDX0, // ipMask
        TCPIP_NETWORK_DEFAULT_GATEWAY_IDX0, // gateway
        TCPIP_NETWORK_DEFAULT_DNS_IDX0, // priDNS
        TCPIP_NETWORK_DEFAULT_SECOND_DNS_IDX0, // secondDNS
        TCPIP_NETWORK_DEFAULT_POWER_MODE_IDX0, // powerMode
        TCPIP_NETWORK_DEFAULT_INTERFACE_FLAGS_IDX0, // startFlags
       &TCPIP_NETWORK_DEFAULT_MAC_DRIVER_IDX0, // pMacObject
    },
};

 
And in my "reconfig" I use:
            TCPIP_NETWORK_CONFIG const config = { /*! Set new config, only IP is configurable at this point */
                .interface = TCPIP_NETWORK_DEFAULT_INTERFACE_NAME_IDX0,
                .hostName = TCPIP_NETWORK_DEFAULT_HOST_NAME_IDX0,
                .macAddr = TCPIP_NETWORK_DEFAULT_MAC_ADDR_IDX0,
                .ipAddr = new_ip_string,
                //.ipAddr = TCPIP_NETWORK_DEFAULT_IP_ADDRESS_IDX0, /* Not used */
                .ipMask = TCPIP_NETWORK_DEFAULT_IP_MASK_IDX0,
                .gateway = TCPIP_NETWORK_DEFAULT_GATEWAY_IDX0,
                .priDNS = TCPIP_NETWORK_DEFAULT_DNS_IDX0,
                .secondDNS = TCPIP_NETWORK_DEFAULT_SECOND_DNS_IDX0,
                .powerMode = TCPIP_NETWORK_DEFAULT_POWER_MODE_IDX0,
                .startFlags = TCPIP_NETWORK_DEFAULT_INTERFACE_FLAGS_IDX0,
                .pMacObject = &TCPIP_NETWORK_DEFAULT_MAC_DRIVER_IDX0,
// .ipv6Addr = NULL,
// .ipv6PrefixLen = 0,
// .ipv6Gateway = NULL,
            };

 
I get new_ip_string as follows:
 
NEW_CLIENT_IP = APP_get_current_ip();
char new_ip_string[20];
memset( new_ip_string, 0, 20 );
TCPIP_Helper_IPAddressToString( &NEW_CLIENT_IP, new_ip_string, 20 );

 
I have a state machine that handles the UDP comms (similar to what is in the Harmony UDP examples) to which I have added a "reconfig" state (for when I want to bring the NetDown & Up) and a "run" state (in which I handle various other stuff), I wanted to wait for TCPIP_STACK_NetIsReady() to return true before I jump back to normal operation.
 
I will try your suggestion first thing tomorrow! 
 
#23
rainad
Super Member
  • Total Posts : 1209
  • Reward points : 0
  • Joined: 2009/05/01 13:39:25
  • Location: 0
  • Status: offline
Re: LAN8720 seems to fail while tcpip stack keeps working? 2019/03/15 06:49:47 (permalink)
0
The TCPIP_STACK_NetIsReady not returning true should not happen. Would it be possible to exercise this sequence NetDown, NetUp, without starting anything else in the application? I mean before starting your UDP and TCP connections.
We need to identify what causes this. If this test/approach works fine, then the next step would be to close all your connections before calling NetDown. Let's see if that works.
 
#24
Frankaas
Starting Member
  • Total Posts : 48
  • Reward points : 0
  • Joined: 2018/12/12 02:02:21
  • Location: 0
  • Status: offline
Re: LAN8720 seems to fail while tcpip stack keeps working? 2019/03/15 08:49:26 (permalink)
0
It unfortunately does not make any difference if I use the exact same parameters as I use for the first call to Stack_Initialize(). Why would this not work?
 
Would it be better to use TCPIP_STACK_Deinitialize and TCPIP_STACK_Initialize?
#25
Frankaas
Starting Member
  • Total Posts : 48
  • Reward points : 0
  • Joined: 2018/12/12 02:02:21
  • Location: 0
  • Status: offline
Re: LAN8720 seems to fail while tcpip stack keeps working? 2019/03/15 09:33:22 (permalink)
0
Sorry, I somehow missed your previous post when I wrote my previous one. I am testing your suggestion as we speak. I only have 1 UDP socket in use which I will close before NetDown, and no TCP. Should I shutdown anything else? I only have ARP and ICMPv4 enabled. 
 
The network succesfully came back once and the second time it hung at:  
TCPIP_NET_HANDLE netH = TCPIP_STACK_NetHandleGet( "PIC32INT" );
if( TCPIP_STACK_NetIsReady( netH ))
 
This is the response on the console to the netinfo command:
 
>netinfo 1
---------- Interface <eth0/PIC32INT> ----------
Host Name: MCHPBOARD_E - NBNS disabled
IPv4 Address: 10.35.39.89
Mask: 255.240.0.0
Gateway: 0.0.0.0
DNS: 0.0.0.0
MAC Address: 54:10:ec:d5:27:59
default IP address is ON
dhcp is disabled
Link is DOWN
 
 
#26
rainad
Super Member
  • Total Posts : 1209
  • Reward points : 0
  • Joined: 2009/05/01 13:39:25
  • Location: 0
  • Status: offline
Re: LAN8720 seems to fail while tcpip stack keeps working? 2019/03/15 13:02:35 (permalink)
0
And why exactly is the link down, is there no Ethernet cable inserted, or this is a different error?
 
#27
Frankaas
Starting Member
  • Total Posts : 48
  • Reward points : 0
  • Joined: 2018/12/12 02:02:21
  • Location: 0
  • Status: offline
Re: LAN8720 seems to fail while tcpip stack keeps working? 2019/03/16 14:47:36 (permalink)
0
The Ethernet cable is inserted. Most of the time the communication (UDP packets back and forth) is working perfectly fine. But when the PHY is (presumably) resetted / upset the communication stops I can clearly see this from the state of the PHY registers. 
 
I've tried using TCPIP_UDP_Close( appData.clientSocket ); before calling TCPIP_STACK_NetDown( netH ) but it makes no difference. 
 
 
#28
Frankaas
Starting Member
  • Total Posts : 48
  • Reward points : 0
  • Joined: 2018/12/12 02:02:21
  • Location: 0
  • Status: offline
Re: LAN8720 seems to fail while tcpip stack keeps working? 2019/03/18 08:11:00 (permalink)
0
I've tested with using the NetDown and then NetUp without opening an UDP socket, so nothing of the stack/network is used by me... It still hangs at NetIsReady :(.
 
Also, if I restart the net while the PHY is oké, it restarts without a problem.
 
I do also have an UDP bootloader in the PIC. The bootloader has a max. no of UDP sockets of 2 of which it uses 1. My application has a max. no of UDP sockets of 1. I don't think this should be of any influence but just in case it somehow is I thought I'd share it.
 
 
post edited by Frankaas - 2019/03/18 08:30:10
#29
Frankaas
Starting Member
  • Total Posts : 48
  • Reward points : 0
  • Joined: 2018/12/12 02:02:21
  • Location: 0
  • Status: offline
Re: LAN8720 seems to fail while tcpip stack keeps working? 2019/03/18 08:44:12 (permalink)
0
Oke, I thought I'd also test using a soft reset to see whether the network would come back up but it does not. Only when I give a hardware reset. Does this mean the only way to get things back on track is to give a hard reset? As far as I could read from the PHY datasheet, the soft reset has the same function and the hardware reset is only really required at power up.
 
Any advice is very welcome!!
#30
rainad
Super Member
  • Total Posts : 1209
  • Reward points : 0
  • Joined: 2009/05/01 13:39:25
  • Location: 0
  • Status: offline
Re: LAN8720 seems to fail while tcpip stack keeps working? 2019/03/18 08:56:44 (permalink)
0
I think that there may be some issues with the board that you're using.
It would be useful if you can do some debugging in the driver at that moment, so we can see what exactly fails - my suspicion that the negotiation never completes, because the PHY is in that weird state. 
Another suggestion: you may turn off the negotiation and select directly 100 Mbps and Full duplex (or whatever is the right parameters for your network) and let's see how that on is behaving.
 
#31
Frankaas
Starting Member
  • Total Posts : 48
  • Reward points : 0
  • Joined: 2018/12/12 02:02:21
  • Location: 0
  • Status: offline
Re: LAN8720 seems to fail while tcpip stack keeps working? 2019/03/18 09:37:46 (permalink)
0
Hi Rainad,
 
I will try to disable auto negotiation and see what happens. I just have to see which register to poll to check whether the PHY is still healthy.
 
I will also try debugging the driver, do you have any idea where I can best start looking?
 
Thank you very much again for sharing your wisdom :)
 
Franka
post edited by Frankaas - 2019/03/20 04:31:18
#32
Frankaas
Starting Member
  • Total Posts : 48
  • Reward points : 0
  • Joined: 2018/12/12 02:02:21
  • Location: 0
  • Status: offline
Re: LAN8720 seems to fail while tcpip stack keeps working? 2019/03/20 07:03:33 (permalink)
0
So, I've disabled auto negotiation (in the Harmony Configurator) and enabled 100Mb/s and Full Duplex. The PHY still gets upset. I've included the MIIM dump below:
 
When all was well:
>Miim Dump Reg: 0, add: 0, val: 0x2100
Miim Dump Reg: 1, add: 0, val: 0x780d (Link is UP)
Miim Dump Reg: 2, add: 0, val: 0x 7
Miim Dump Reg: 3, add: 0, val: 0xc0f1
Miim Dump Reg: 4, add: 0, val: 0x 1e1 (10Mbps with full duplex ability)
Miim Dump Reg: 5, add: 0, val: 0x 1
Miim Dump Reg: 6, add: 0, val: 0x 0
Miim Dump Reg: 7, add: 0, val: 0xffff
Miim Dump Reg: 8, add: 0, val: 0xffff
Miim Dump Reg: 9, add: 0, val: 0xffff
Miim Dump Reg: 10, add: 0, val: 0xffff
Miim Dump Reg: 11, add: 0, val: 0xffff
Miim Dump Reg: 12, add: 0, val: 0xffff
Miim Dump Reg: 13, add: 0, val: 0xffff
Miim Dump Reg: 14, add: 0, val: 0xffff
Miim Dump Reg: 15, add: 0, val: 0x 0
Miim Dump Reg: 16, add: 0, val: 0x 40
Miim Dump Reg: 17, add: 0, val: 0x 2 (ENERGYON)
Miim Dump Reg: 18, add: 0, val: 0x60e0 (MODE bits all on)
Miim Dump Reg: 19, add: 0, val: 0xffff
Miim Dump Reg: 20, add: 0, val: 0x 0
Miim Dump Reg: 21, add: 0, val: 0x 0
Miim Dump Reg: 22, add: 0, val: 0x 0
Miim Dump Reg: 23, add: 0, val: 0x 0
Miim Dump Reg: 24, add: 0, val: 0xffff
Miim Dump Reg: 25, add: 0, val: 0xffff
Miim Dump Reg: 26, add: 0, val: 0x 0
Miim Dump Reg: 27, add: 0, val: 0x801b (XPOL Polarity state of the 10BASE-T: 1 = Reversed polarity)
Miim Dump Reg: 28, add: 0, val: 0x 0
Miim Dump Reg: 29, add: 0, val: 0x 10
Miim Dump Reg: 30, add: 0, val: 0x 0
Miim Dump Reg: 31, add: 0, val: 0x 58
 
After event:
>Miim Dump Reg: 0, add: 0, val: 0x2100
Miim Dump Reg: 1, add: 0, val: 0x7809 (Link is DOWN)
Miim Dump Reg: 2, add: 0, val: 0x 7
Miim Dump Reg: 3, add: 0, val: 0xc0f1
Miim Dump Reg: 4, add: 0, val: 0x 1a1 (no 10Mbps with full duplex ability)
Miim Dump Reg: 5, add: 0, val: 0x 1
Miim Dump Reg: 6, add: 0, val: 0x 0
Miim Dump Reg: 7, add: 0, val: 0xffff
Miim Dump Reg: 8, add: 0, val: 0xffff
Miim Dump Reg: 9, add: 0, val: 0xffff
Miim Dump Reg: 10, add: 0, val: 0xffff
Miim Dump Reg: 11, add: 0, val: 0xffff
Miim Dump Reg: 12, add: 0, val: 0xffff
Miim Dump Reg: 13, add: 0, val: 0xffff
Miim Dump Reg: 14, add: 0, val: 0xffff
Miim Dump Reg: 15, add: 0, val: 0x 0
Miim Dump Reg: 16, add: 0, val: 0x 40
Miim Dump Reg: 17, add: 0, val: 0x 0 (no ENERGYON)
Miim Dump Reg: 18, add: 0, val: 0x6000 (MODE bits all off)
Miim Dump Reg: 19, add: 0, val: 0xffff
Miim Dump Reg: 20, add: 0, val: 0x 0
Miim Dump Reg: 21, add: 0, val: 0x 0
Miim Dump Reg: 22, add: 0, val: 0x 0
Miim Dump Reg: 23, add: 0, val: 0x 0
Miim Dump Reg: 24, add: 0, val: 0xffff
Miim Dump Reg: 25, add: 0, val: 0xffff
Miim Dump Reg: 26, add: 0, val: 0x 0
Miim Dump Reg: 27, add: 0, val: 0x800b (XPOL Polarity state of the 10BASE-T: 0 = Normal polarity)
Miim Dump Reg: 28, add: 0, val: 0x 0
Miim Dump Reg: 29, add: 0, val: 0x 10
Miim Dump Reg: 30, add: 0, val: 0x 0
Miim Dump Reg: 31, add: 0, val: 0x 58
 
I've put debug lines throughout the PHY initialization code and according to the console output, it makes it to the end of the DRV_ETHMAC_PIC32MACTasks with a status ready (this is the same with/without auto negotiation). I have not found yet where exactly the PHY is reset. It is also weird that when all is well, all 3 mode bits of the PHY are 1 (which means that auto negotiation is enabled as well as 10Mb/s and half duplex, which I thought I'd disabled in the MHC). These are the settings that are made with the configuration straps but as far as I understood from the LAN8720 datasheet, these settings can be overwritten later on.
 
The datasheet says this: 
The MODE[2:0] configuration straps control the configuration of the 10/100 digital block. When the nRST pin is deasserted, the register bit values are loaded according to the MODE[2:0] configuration straps. The 10/100 digital block is
then configured by the register bit values. When a soft reset occurs via the Soft Reset bit of the Basic Control Register,
the configuration of the 10/100 digital block is controlled by the register bit values and the MODE[2:0] configuration
straps have no affect.

Perhaps this means that these MODE[2:0] bits always match the config straps at startup or after a reset but are only used after a hard or power up reset? To me, this also suggests that it is possible to (re)configure the registers as desired and issue a soft reset and then everything should go back to normal.
 
 
 
 
post edited by Frankaas - 2019/03/20 08:20:56
#33
rainad
Super Member
  • Total Posts : 1209
  • Reward points : 0
  • Joined: 2009/05/01 13:39:25
  • Location: 0
  • Status: offline
Re: LAN8720 seems to fail while tcpip stack keeps working? 2019/03/20 09:51:25 (permalink)
0
If the PHY gets reset because of EMI or some other noise issues, it can happen that it does not perform the reset properly and has strange values for the mode bits and other strap configurations.
Try to connect an I/O pin to the PHY reset pin and when you turn up the network interface specifically toggle the PHY reset pin. This may bring the PHY to the correct state. There is a callback that you can use: the DRV_ETHPHY_INIT::resetFunction exists exactly for this purpose.
 
#34
Frankaas
Starting Member
  • Total Posts : 48
  • Reward points : 0
  • Joined: 2018/12/12 02:02:21
  • Location: 0
  • Status: offline
Re: LAN8720 seems to fail while tcpip stack keeps working? 2019/03/21 06:09:39 (permalink)
0
Hi Rainad,
 
I didn't want to go there because it would mean a hardware mod on a lot of existing hardware and I had much rather solved it in software but it seems like I have no choice. I've tried it and it works like a charm so for now we have a fix and I won't bug you about it anymore ;).
 
A lot of thanks for all your help!
 
Franka
#35
rainad
Super Member
  • Total Posts : 1209
  • Reward points : 0
  • Joined: 2009/05/01 13:39:25
  • Location: 0
  • Status: offline
Re: LAN8720 seems to fail while tcpip stack keeps working? 2019/03/21 13:35:52 (permalink)
0
Good to hear that you got it working.
Having a way to hardware control the PHY reset seems like the safe thing to do under these circumstances.
#36
nornor
New Member
  • Total Posts : 9
  • Reward points : 0
  • Joined: 2018/04/11 07:02:59
  • Location: 0
  • Status: offline
Re: LAN8720 seems to fail while tcpip stack keeps working? 2019/06/25 03:27:03 (permalink)
0
hello,
I think i'm facing the same problem. I'm using the standard microchip ethernet starter kit II. 
 
Everthing was fine but when the independent power voltage 230Vac is too close to the Ethernet plug, like less than 5cm, and the relay switch off/on, sometimes the ethernet connection drop (the leds of the plug blink or stop anomaly for 1 seconds). the program is still running but it's impossible to connect anymore. I have to reset the board to connect again. 
 
so i tried the solution from this thread but i don't have error at if(opRes < 0). opRes is always pending and ok. Did this work for you @Frankaas ? or is there anything to add ?
 
I started to look at datasheet for other register or status but there are many of them like DRV_GMAC_Status, DRV_ETHPHY_LINK_STATUS and dozen of them... so before trying anything randomly, maybe someone know where to look ? thanks ! 
 

Attached Image(s)

#37
Frankaas
Starting Member
  • Total Posts : 48
  • Reward points : 0
  • Joined: 2018/12/12 02:02:21
  • Location: 0
  • Status: offline
Re: LAN8720 seems to fail while tcpip stack keeps working? 2019/06/28 14:19:02 (permalink)
0
Hi Nornor!
 
The PHY is a very sensitive device and very careful design of its surroundings is an absolute must for it to operate in a reliable manner. I will never make the mistake again of assuming that another manufacturer did this right, it has caused me a lot of headache ;).
 
You say you tried the solution from this thread, which solution do you mean exactly as I have tried numerous? In my case, the only thing that works consistently is to give the PHY a hard reset (physically pull its reset line down), all other approaches either failed or only worked in some cases. In case of a reset, it takes approximately 2,3 seconds (most of that time is needed for the auto negotiation) before the connection is back up. I don't know if this is an option for you but maybe you can elaborate a little on what you have tried and what the requirements are for your project and I will of course try to help!
#38
nornor
New Member
  • Total Posts : 9
  • Reward points : 0
  • Joined: 2018/04/11 07:02:59
  • Location: 0
  • Status: offline
Re: LAN8720 seems to fail while tcpip stack keeps working? 2019/07/01 06:06:07 (permalink)
0
hello,
thank you fo your answer. What I've tried was to detected the break, the message for Rainad said permalink
  
...
DRV_MIIM_RESULT opRes = miimObj->DRV_MIIM_OperationResult(miimHandle, miimOpHandle, &opData);
if(opRes == DRV_MIIM_RES_PENDING)
{ // ongoing...
return;
}
if(opRes < 0)
{ // error occurred
// display smth, etc., abort
}
...
 
I never have "opRes < 0" . So i can't see when the phy is 'down' . If i can detect it, indeed i can try to reset the phy. I didn't have time between the last message and now to look further. Did you use this method of detection ? 
#39
Frankaas
Starting Member
  • Total Posts : 48
  • Reward points : 0
  • Joined: 2018/12/12 02:02:21
  • Location: 0
  • Status: offline
Re: LAN8720 seems to fail while tcpip stack keeps working? 2019/07/02 00:08:07 (permalink)
0
Hi Nornor,
 
I most certainly use the MIIM driver to read the PHY registers.
The opRes is simply the result of the MIIM read operation (whether it is still ongoing, or finished and succesful, or finished and an error occured, which is when opRes < 0) and not the content that was read from the registers.
You do not want "opRes < 0" to be true because that means that something went wrong with reading the PHY registers. At least in my case, the PHY can still be reached with MIIM, it just gets into a funky state and the ethernet connection is down, that is in your case probably also why opRes <0 is never true.
 
What I ended up doing is look for consistent differences in the content of the PHY registers during normal operation versus after the PHY was down and found a setting that I could use to check whether the PHY is down. If I detect this difference, I reset the PHY and the connection comes back up.
 
By the way, do you have a snubber of some kind across the relay(s) and (if applicable) its inductive loads? In my case it was possible to decrease the frequency of the PHY failing by adding snubbers here and there as well as a strategically placed common mode choke. Also physically separating the various signals as much as possible can make a huge difference. 
 
I hope this helps,
 
Franka
post edited by Frankaas - 2019/07/02 00:13:32
#40
Page: < 123 > Showing page 2 of 3
Jump to:
© 2019 APG vNext Commercial Version 4.5