F28M35x Ethernet Does Not Initialize Until 150 Seconds

is there any difference in the PHYRST signal levels on REV0 and REVA? on REV0 we have an errata on the PHYRST pin is it coming into play?

Best Regards

Santosh

Santosh,

After looking at the PHYRST line with a scope, there is no observable difference between the Rev0 and RevB devices. We had looked at the PHYRST erratum, but don't think that we are having an issue because of it. The attached scope capture is from device power-on. Channel 2 is the 3.3v supply rail and channel 1 is the PHYRST line. I have taken captures from both Rev0 and RevB devices, and they are identical.

Have you connected any MCU GPIO to the PHYRTSn pin on the board or the PHYRSTn pin is simply pulled HIGH?

On M35x REV0, when EMAC controller on the board is reset by SW, it will not reset the PHY automatically, but on REVB it does - provided there is a GPIO pin configured for that peripheral function and that GPIO is routed to the PHYRSTn pin of PHY physically on board. So on REV0 since power up your PHY is active, but on REVB when your SW does initialize the EMAC (GPIO configuration for EMAC and reset of EMAC controller) your PHY should be reset too - I was hoping that could be the problem. But

Could you reproduce the behavior with a simple control suite Ethernet based example, just to rule out TIRTOS or other SW initialization problem?

Best Regards

Santosh

Santosh,

On our board, the PHYRSTn line is connected to the 3.3v supply rail via a resistor and to the F28M35H52C1 pin 97 (J7). Our software configures this pin exactly as the demo project does. After the initial reset at power-on, we never observe the line being pulled low again.

Our original selection of TI-RTOS was driven largely because we could never get the MWare Ethernet examples (neither lwip nor uIP) to build or run. I tried importing the enet_uip_m3 demo from the v201 MWare folder, set the device variant and connection in the project properties and tried to build, but I receive numerous "could not open source file" errors. If you can tell me how to fix this or provide a .out file that will run, I would be glad to try it.

In addition, we did try building the project using the newer TI-RTOS v1.10.00.23, but observed the same results.

I was able to build the controlsuite lwip example for F28M35x - C:\ti\controlSUITE\device_support\f28m35x\v201\F28M35x_examples_Master\enet_lwip without any problems.

I'm not yet sure how looking at LEDs can tell if something is wrong in HW, we might need a more decisive test than that.

Can you confirm you are running same version of SYSBIOS SW on both REV0 and REVA. Its exactly same SW showing different behaviors on REV0 and REVA? or did the sysbios version change when you moved to REVA?

Best Regards

Santosh

Santosh,

I was able to build the lwip example and load it to the device. The LEDs light immediately, but there is never any Ethernet traffic from the device.

We are using the same version of SYSBIOS (6.34.04.22 which comes bundled with TI-RTOS 1.01.00.25) on both Rev0 and RevB devices. The same software which exhibits the long delay on RevB devices works as expected when loaded to a Rev0 device. We did try migrating the project to the newer version of TI-RTOS (1.10.00.23 with the accompanying SYSBIOS 6.35.01.29), but to no effect.

EGold,

yes, the example is a httpd, so it waits for a client to connect. Let me move this forum post to SYSBIOS team and see if they have any ideas/tests.

if your LWIP is configured for DHCP it should send out packets soon after the network state is live.

Best Regards

Santosh

Egold, Santosh

I am going to move this thread to the BIOS forum to see if the experts there have some thoughts.   Links to this thread will continue to work after them move. 

Regards

Lori

The lwip project is configured for DHCP by default, so I would have expected to see a DHCP request after initialization was complete, but there was never any traffic from the device.

Regardless, we did manage to track down a fix. Our project is based on the TI-RTOS demo project. In that project in the TMDXDOCKH52C1.c file, line 229 sets several of the MII interface lines (including MII_PHYRSTn) to GPIO_PIN_TYPE_STD. Since this is the default pin type anyway, we removed this call to GPIOPadConfigSet, and the delay disappeared.

Hi,

Can you attach the modified file? It great to hear that it works for you know, but we like to understand it better. If this is the true fix, we'll incorporate it in the next release.

Todd