EK-TM4C1294XL: Ethernet Connection Issue

Hi Charles,

  Can you clarify a few questions for me?

 - Is your board a server or a client?

 - Do you have another board that you can run and can you repeat the same problem on a different board?

  - After you reset the MAC address, did you reprogram a new MAC address again? You must have a valid MAC address to work. Since you said the board will work after a few hours, I assume you have a MAC address. 

 - If you don't have another board, can you run a different Ethernet example. Please try the enet_tchecho_server or enet_lwip examples in TivaWare? Do you have any connection issues running these examples. These examples are proven and should work. If there is no problem running these examples, then it proves that your network is fine. The problem is most likely on your firmware. If you also see problem running the TivaWare Ethernet examples, then the problem is likely either in your network or the board. If you have another board then you can prove if it is a board problem. If both boards have the same problem then it is definitely network related. 

 - What is ChatServer firmware and where did you get this firmware from? What is the TCP/IP stack based on? Is it based on LwIP or some other providers? I'm not familiar with this software. If the issue is with this software, you will need to contact the vendor who supplies you this software.

  - Last thing is to use the wireshark to trace the traffic. Compare the wireshark traces between the ChatServer and the TivaWare example if there is no issue running the TivaWare example. 

Hi Charles Tsai,

Sorry, I was working on another project for a couple days, so I didn't reply you back on time.

Thanks for you advices. I do have two boards, and that's how the magic things happen. There is one board (board 1) I used for testing for a long time, and another brand new board (board 2) which I just opened for this testing. I got the firmware from Energia examples, and load the Chatserver firmware to the board1. I ran the Chatserver as a server several times, even resetting the MAC a few time, I couldn't get a chance to connect to the server with Tera Term.

I was thinking it might be damaged by resetting the MAC address, so I loaded the firmware to board2, after second trial, the firmware works on board2. Then I came back to board 1 without any changes, it starts working as well. I don't believe it is the firmware or network issue. I think the firmware somehow cannot catch the MAC address after resetting.

I would like to know if it is possible that the board's network connection becomes unstable after MAC address resetting. Are you familiar with the procedures to reset MAC address in "LM Flash Programmer"? The software pops up instruction window a few times to ask you hold or release reset button during MAC address reset, but I skipped all actions and just kept clicking OK on the screen. It seems the MAC address was erased by doing so and I have put new MAC address successfully. May I know the rational behind these required actions?

I will do a few  more tests today to see if the issues can be duplicated.

Thanks,

Another Charles

Hi Charles,

Charles Lin1 said:

I would like to know if it is possible that the board's network connection becomes unstable after MAC address resetting. Are you familiar with the procedures to reset MAC address in "LM Flash Programmer"? The software pops up instruction window a few times to ask you hold or release reset button during MAC address reset, but I skipped all actions and just kept clicking OK on the screen. It seems the MAC address was erased by doing so and I have put new MAC address successfully. May I know the rational behind these required actions?

If you have successfully reprogrammed the MAC address then you should be fine. Can you confirm if you press the "Get Current MAC Address", a valid MAC address is returned? If you don't have a MAC address, then it will not cause unstable issue. It simply will not work at all as the Ethernet frame requires a MAC address as part of the protocol. You said it will suddenly work again. So you must have a good MAC address in my opinion. We just don't know what is the problem with the board1 yet. As suggested earlier in my last reply, can you try other Ethernet examples in the TivaWare? E.g. enet_lwip or enet_tchpecho_server? Do you see any problem with it on the board1?

Thanks for your prompt reply.

I have tried these two Ethernet examples in the TivaWare, and they are working on the board 1, even no issue with Energia examples today.

I have another customized board (board 3). When I load these two example firmware to the board3, it repeats "Waiting for IP address", "Waiting for link". It seems the firmware detects the MAC address, but cannot obtain a valid IP address from DHCP server. Do you know any techniques to debug for such issue? I am thinking to read the related register values and comparing them to the board1. Are there any APIs can do registers reading, I didn't find any.

Thanks for you help.

Regards,

Charles

Hi Charles,

  Ok, looks like the board1 is working and we probably can leave it aside for now and just focus on board3 then. 

  Your board3 problem is most likely hardware related. Can you use the wireshark to capture any traffic. If you are not seeing any traces on wireshark then it kind of tells me the link is not established. The link up is not part of the TCP/IP. The on-chip PHY needs to negotiate with the network partners at the physical layer level. Please first compare the wireshark between the working board and the bad board and see if my reasoning is true or false. If it is the link issue, please compare your custom board design with the LaunchPad board. Can you identify any differences? Do you have the RBIAS connected to GND via a 4.87k resistor?

  As the Christmas and holidays is coming, please expect delay in my response. 

The custom board is basically same as the Launchpad board, only the RJ45 connector is different. There is a 4.87K resistor between RBIAS and GND. Only a few of custom boards have the ethernet issue while others are working. One of not working board has MAC address reset, not sure if the client did the same thing on the other not functioning board. That is why I am sticking with the MAC address issue. I will use the Wireshark to detect the connection as you suggested.

Thanks for your advice. Don't worry about the delay, you are the most responsive supporter I have in TI forum. Wish you have a nice holiday!

Sincerely,

Charles

Thanks for the additional info. Now I get that you have several custom boards and out of which a few will have problems but not all of them. This is interesting. What MAC address on the not working boards do you have? First, please make sure you can read back the MAC address in LM flash programmer. Secondly, make sure that each MAC address is unique. Is it possible that you have other boards on the network with the same MAC address. This will cause problem. This is the only thing I can think of at the moment that can relate to the MAC address. Normally, you will only use the MAC addresses from the pool that is assigned to your company. 

I have tried a few different MAC addresses, most of which are provided by the client, I even tried with the MAC address of the board1. But I am sure only one unique MAC address connect to the network at a time. 

I am able to read the MAC address back in LM flash Programmer after resetting.

I will get back to you soon after I have Wireshark detected on the connection. 

Regards,

Charles

Let me know how the wireshark traces look like between the good boards vs the bad ones. Have a nice holiday!

Hi Charles,

Sorry for the late reply. I left some non-working boards in the office and I just came back to the office today to test all of them. Here are what I found.

The firmware I loaded is called "DHCP address printer". Basically, we assigned the MAC address to the board and it gets IP address automatically. And I connected PC and the boards to the LAN ports on same router.

I tested TI development board and non-working custom boards, with two TP-LINK (speed: 450M and 1G) routers I have at home. All of them are actually working. I am able to ping the device in the "command Prompt" and able to catch the connection in the Wireshark. However, when testing with another router (Hitron 1G), TI board works but the custom board stops working. The LED light on the LAN port lights up, but no connection detected for the custom board.

Considering that the custom boards are working with some routers,  do you think we can exclude the hardware issue?

I have attached several screenshots on Wireshark for both TI development board and custom board. Because there is no connection built between custom board and Hitron router, I could not capture the connection in PHY level with my computer even I turned on the promiscuous mode.

Thanks,

CharlesWireshark Screenshots.rar

Hi Charles,

  I'm still on vacation until next Monday. I don't know why your custom board works with one brand of router but not the other while the LaunchPad works with both. Perhaps there is some configuration differences between the two routers but that is just my guess. Do you have another Hitron router that you can repeat the same issue?Can you also contact the router vendor for suggestion as they are the expert on their products and I hope they can shed some light too. I also don't know what firmware you are using. Last time, you mentioned some Energia examples which we don't really support as stated in our FAQ. Can you try our TivaWare Ethernet examples? These examples also acquire the IP address via the DHCP. Do you have the same problem running these examples to acquire the DHCP address your board3?

Hi Charles,

I will do more tests as you suggested and post updates next Monday. Enjoy your vacation and wish you the best for the new year. 

Best Regards,

Charles

Hi Charles,

 Thank you. I will follow up with you on Monday for your updates.

Hi Charles Tsai,

Happy new year! I have loaded the example of "enet_lwip" on the custom board and tested it with several routers and one switch.

Here are the results:

1. On two different TPlink routers, no issue found. The DHCP server assigns regular IP address and the board responses normally when you ping it and I am able to open the local webpage with the IP address. The device connection speed to the routers are 100M. The max speed for the routers are 450M and 1000M.

2. I managed to test on two same Hitron Routers, on both of them, the DHCP did assign an IP address - 169.254.240.253, I could see the device is connected with 100M speed in the router admin page, but it shows "destination host unreachable" when pinging it, and the webpage cannot be open. I searched the information a bit, one person suggests it might be the device pulls too much power through PoE, but after I disconnected the PoE pins on RJ45 from the board, it behaves same. And there is definitely no other devices with same IP address connected to the router. 

3. On the switch, it assigns same IP address as the Hitron Routers. Cannot be pinged.

4. Another router in the office. It just keeps rotating the messages "waiting for link" "waiting for IP address". I cannot do much on this router.

The TI TM4C1294 launch pad board works on all these scenarios described above.

Do you have any ideas how to troubleshoot it further? I am thinking there might be something wrong with network interface, do you know any examples or easy methods to access to the ethernet controller registers? I would like to read the status of these registers to see if anything goes wrong. 

Thanks,

Charles

Hi Charles,

  Which router is the wireshark capture corresponding to? Is the wireshark capture based on the TPlink or the Hitron?

Charles Lin1 said:

2. I managed to test on two same Hitron Routers, on both of them, the DHCP did assign an IP address - 169.254.240.253, I could see the device is connected with 100M speed in the router admin page, but it shows "destination host unreachable" when pinging it, and the webpage cannot be open. I searched the information a bit, one person suggests it might be the device pulls too much power through PoE, but after I disconnected the PoE pins on RJ45 from the board, it behaves same. And there is definitely no other devices with same IP address connected to the router. 

  Do you see the IP Address displayed on the COM port with the Hitron router when running the enet_lwip? I wanted to confirm if the 169.254.240.253 is displayed on the COM port or this is only shown in the router. In my past experience, I will see DHCP Discover and later DHCP Request. It is the DHCP request the client is making an official request of the IP address. However, I don't see that in your wireshark capture. It didn't seem to me the IP address is acquired by the MCU yet.

  You can look at the EMAC registers in the register window. Try to compare between the TPlink and Hitron on your custom board. Can you tell any difference?

To read the PHY registers you need to use the EMACPHYRead API. For example, to read the EPHYBMSR register in the PHY you will call 

Hi Charles,

Thanks for your reply. The IP address is shown on the COM_Port. I didn't see the custom board's IP address on the router admin page. On the admin page, I can only see one device is connected with 100M speed. And if I disconnect the custom board from the router, this device will disappear on the admin page.

And this 169.254.x.x IP address is not regular IP address, it is called "Automatic Private IP Addressing". According to the information I got online, it means the custom board could not find the DHCP server, then it assigns itself a "fake" IP address. I guess that's why you cannot see the DHCP request, it tried DHCP discover 3 times and then failed. The custom board starts giving itself a "fake" IP address. In previous post, I shouldn't say the " the DHCP did assign an IP address - 169.254.240.253", my bad.

Do you use Code Composer Studio to display the EMAC0 register? I have some trouble to use this software, I would need sometime to figure it out. I cannot even build the example project after I changed some settings. I will let you know the result when I am able to access the registers.

Best Regards,

Charles

Hi Charles Tsai,

Sorry for the late updates. I was working on another project for a couple days. 

Here are the updates:

1. I tested the custom board with the 1000M TPLINK, I found that it was not working all the time, maybe less 1/10 chance, it generates the connection with regular IP address. If it doesn't work, I just kept resetting the board and reconnecting the ethernet cable until it works. I was not doing enough tests with this router and was lucky to see it works. Same successful connection rate can be applied to the switch I have here.

2. I read the compared the EMAC0 register values, and I didn't get much valuable information there. EMAC_CFG register has either 0XCC0C or 0X8C0C, I caught both values for 450M TPLINK, which is always working. I included the package for the screenshots in case you need a reference.

3. I tried to read the PHY register. I found that there were two values for EPHYBMSR, 0x7849 and 0x786D. When it goes to 0X786D, it connected. The two different bits are linkstate and auto-negotiated. When connecting to the router in the office, it keeps rotating 0x786D and 0X7849 every couple seconds, it seems to be forced to reset when it is in auto-negotiated mode. 

4. According to the phenomenon described in 3 and it works constantly with 450M router. I think it is the speed issue. I am thinking to set the PHY register in forced mode to see what is going to happen. I will update you soon. Please let me know if you have any thoughts.

Thanks,

Charles

Ethernet Port Debug.rar

Hi Charles,

  Thanks for the updates. 

  While I don't know the root cause to the issue on your custom board, I feel the problem is in auto-negotiation between your board and the router. The auto-negotiation is handled by the PHY and this is before the TCP/IP stack is running. I found this below document which will help you and also I understand a bit better on the auto-negotiation. You might want to compare the FLP as described in the document between the launchPad and your board. 

https://www.iol.unh.edu/sites/default/files/knowledgebase/ethernet/Copper_ANEG_JEFF_LAPAK.pdf

 Another suggestion I will make is to do a ABA swap test. You stated the LauchPad always works with any routers/switches. Can you swap the MCU between the LaunchPad and your custom board? Will the LaunchPad MCU continue to work in your custom board? What about the MCU from the custom board being put on the LaunchPad? Will it continue to fail? I just wanted to make sure there is no damage to the MCU on your custom board. If you don't want to swap the MCU out of the LaunchPad, do you have another spare and fresh MCU that you can try on the problem board?

Hi Charles,

Thanks for your suggestions and your patience. 

After I forced the PHY to 10-BASE, all the custom boards are working with Hitron router and the router in the office. However, they only work with the switch from time to time no matter what setting I put on PHY configuration.

I probably need to do some hardware replacement in next step like you suggested. One board has a brand new MCU, but it has MAC address reset by LM Flash Programmer. I actually still concerned if MAC address resetting will damage the MCU somehow, because I believe at least two of these three not working custom boards have been reset, even though there is no issue with MAC resetting on lauchPad board.

Thanks,

Charles

Hi Charles,

  Programming the MAC address is a matter of writing to the non-volatile USER_REG0 and USER_REG1 registers. The programming of the MAC does not involve the EMAC and the PHY. I don't think there is any reason to believe the MAC address programming can "damage" the device.

Once the MAC address is stored, the application merely reads it and pass it to the LwIP stack. Please see below snippet of code. I simply can't make sense the MAC address programming would damage the device. I can understand the MAC address isn't successfully programmed but it will be just a corrupted value read but you have demonstrated that you can always "unlock" the device and reprogram the address and read it back correctly in LM flash programmer. 

    //
    // Configure the hardware  address for Ethernet Controller filtering of
    // incoming packets.  The  address will be stored in the non-volatile
    // USER0 and USER1 registers.
    //
    MAP_FlashUserGet(&ui32User0, &ui32User1);
    if((ui32User0 == 0xffffffff) || (ui32User1 == 0xffffffff))
    {
        //
        // We should never get here.  This is an error if the  address has
        // not been programmed into the device.  Exit the program.
        // Let the user know there is no  address
        //
        UARTprintf("No  programmed!\n");
        while(1)
        {
        }
    }

    //
    // Tell the user what we are doing just now.
    //
    UARTprintf("Waiting for IP.\n");

    //
    // Convert the 24/24 split  address from NV ram into a 32/16 split 
    // address needed to program the hardware registers, then program the 
    // address into the Ethernet Controller registers.
    //
    pui8MACArray[0] = ((ui32User0 >>  0) & 0xff);
    pui8MACArray[1] = ((ui32User0 >>  8) & 0xff);
    pui8MACArray[2] = ((ui32User0 >> 16) & 0xff);
    pui8MACArray[3] = ((ui32User1 >>  0) & 0xff);
    pui8MACArray[4] = ((ui32User1 >>  8) & 0xff);
    pui8MACArray[5] = ((ui32User1 >> 16) & 0xff);

    //
    // Initialize the lwIP library, using DHCP.
    //
    lwIPInit(g_ui32SysClock, pui8MACArray, 0, 0, 0, IPADDR_USE_DHCP);

Have you tried to force to 100-BASE? Will it work at 100-BASE or only 10-BASE? 

If your brand new MCU will work in all the routers/switches the first time then it means the old MCU may be damaged for reasons that is not related to the MAC address programming. I suspect the brand new MCU may gradually degrade like your old MCU. If the brand MCU acts just like the old MCU where it partially works then it is more a hardware issue on the PCB to me.  I don't think I have seen your custom board schematic on the PHY connection. Do you have the recommended transformer and the ESD diode protection?  If there is any concern of damage to the chip then you must ensure there is proper ESD protection on the pins. Please follow the recommendation in the TM4C129 system design guidelines. https://www.ti.com/lit/pdf/spma056

Hi Charles,

I did have tests on forcing PHY to 100-BASE, but it doesn't work no matter it is in FULL or HALF duplex. I was lost and most of these not working boards have the MAC address reset before, that is why I guess there might be a relation.

The RJ45 connector on the custom board is https://www.digikey.ca/en/products/detail/w%C3%BCrth-elektronik/7499211125/4429038. It includes the transformers, but there is no ESD protection between the RJ45 and the MCU. The schematic was not designed by myself, so I would need to get the authorization before I can show it here, sorry.

These custom boards are basically all new, they are just for the prototype and testing. I don't think the MCU degraded so fast. The board with a new MCU replaced, has MAC address been rewritten and then returned to us, I didn't do the ethernet function test beforehand. It can't prove anything unless I replaced it with another new MCU now.

Regards,

Charles

Thanks, Charles.

We will replace the MCU and try to add the ESD protection. I will update you later.

Hi Charles,

  Yes, please report back your new findings. I will expect the new MCU to initially work for a while. As indicated, the TVS diodes are paramount for ESD and transient events suppression. 

Hi Charles,

  Really glad to hear you resolve the issue!