TM4C129DNCZAD: External Ethernet PHY example

Charles -
Thanks for the reply. I reviewed the old MII post above and it did shed some light on a few things, so thanks for that. However, I'm still not out of the woods yet.

I discovered to my surprise that the MDIO line can fire out lots of data before the 50MHz MDC/REFCLK line is provided by an external PHY... this is perplexing to me, as I thought the MDIO line has to have an external clock before it will 'latch' out each data bit on the clocks edges? (like a SPI bus?) Or do I not fully understand how TI's implementation of this RMII interface works?

Hi Kelly,

  Please refer to the block diagram in the datasheet. I have also shown below. MDC is the clock for MDIO which is produced by EMAC module. MDC clock is different from the REFCLK.

23.3.12 Serial Management Interface
The Ethernet MAC has the ability to program an external PHY through the external EN0MDIO and
EN0MDC signals. The EN0MDC signal is a 2.5 MHz clock that is sourced from System Clock (SYSCLK)
and then divided down to the required frequency by programming the CR field in the Ethernet MAC
MII Address (EMACMIIADDR) register. The available addresses for the PHY are 0x01 to 1F.

Thanks Charles - Following up here, apologies for the long post, but hoping if we can't use these TI parts at least we can pay the knowledge forward.

Upon further review of the example link you provided, it unfortunately doesn't apply. The RMII connection is broken out on the header pins, but they are not used. The operational Ethernet jack demo'ed uses the internal PHY like other TI EVK boards in the TM4C129 family.
------------------------------------------------
One code issue that we discovered and fixed - (from my more recent reply above) There is no boundary/error check or trap on the Tivaware (v2.1.4.178) driver function EMACInit(). It will accept a ui32SysClk value of zero (yes, our code is at fault) but that Tivaware function sets the MDC clock 3.5x higher than the max frequency allowed. And for reference, when that is the case, the MDC/MDIO bus works intermittently which is hard to troubleshoot. Overall this is "my bad" but this could be a possibility in other edge cases and other driver functions, so something to watch out for (to help others who might read this post).
------------------------------------------------
A second issue appears to be a hard stop and something inside the silicon/documents, that likely only TI can help with. Waveforms and tests have proven that the external PHY (in our case 88E6320) is set up properly via the MDC/MDIO bus and REFCLK is 50MHz/stable. Using the code that functions on our TI EVK in the enet_lwip example, and defining EMAC_PHY_IS_EXT_RMII on our board (instead of EMAC_PHY_TYPE_INTERNAL), no RMII interrupts or arrival of data occurs. Doing the minimum but required changes from the working enet_lwip example on our EK-TM4C1294XL, results in the packets no longer appearing in Wireshark when using an SMI RMII external PHY.

In the TM4C129DNCZAD datasheet (revision 15863.2743) section 23.4 Ethernet contorller "Initialization and Configuration" (pg 1584), the steps indicate the ECEXT bit and PINTFS need to be programmed, but on register pgs 1589-1704 the ECEXT bit does not exist and EMACPC (which should contain PINTFS) is read only. We have yet to find any example code or driver libraries that spell out external PHY init steps that can be successfully executed (maybe we just haven't searched the right place).

There are e2e forum posts dating back 7 yrs indicating similar issues in TM4C parts (one of which is the link you shared above, others I share below). After reading through the solutions described in these posts and inspecting the files they attached, it appears others only get the PHY comm bus (MDC/MDIO) configured successfully, but they do not solve the Ethernet data bus link issues (as the last post in your e2e link above indicates). Unless TI expertise can provide steps that show otherwise, unfortunately we will be lead to the conclusion that the external PHY support for RMII was never fully developed/tested and there is not a way to make it fully functional in these parts.

Might there be a datasheet errata somewhere indicating this? Or an informal or unreleased addendum document that has revised init steps? Either of those would help direct designers appropriately, or manage designers expectations to not use these parts for this purpose. The goal being to prevent unnecessary investments of time and hardware by other designers in the future.

This is our last ditch effort to keep a TI processor in our design, as management is considering options and impact of a different uP from a different mfg. Any help you can provide, or TI experts on this part family you can connect with, is greatly appreciated. Please advise, and thank you for your time.

e2e.ti.com/.../tm4c1292-emac

e2e.ti.com/.../tm4c1292-ncpdt-ethernet

Hi Kelly,

Kelly Williams said:

thernet contorller "Initialization and Configuration" (pg 1584), the steps indicate the ECEXT bit and PINTFS need to be programmed, but on register pgs 1589-1704 the ECEXT bit does not exist and EMACPC (which should contain PINTFS) is read only.

I think it is probably a documentation mistake for ECEXT. I think this bit is immaterial. If external PHY is chosen then the external REFCLK will be used. Perhaps at one point of time, ECEXT existed but later removed due to redundancy. As far PINTFS, it is shown as RW in the datasheet. With all that said, I wish I could help for the RMII. Do you know if your external PHY is properly configured? Do you see any signals wiggling on the RMII interface after the PHY is configured?

Hi, Charles.

That's one of the things we've been looking for!  Which datasheet did that come from?  The TM4C129DNCZAD datasheet we downloaded from the TI website (SPMS440B, dated June 18, 2014) shows this for EMACPC:

Did we download the wrong datasheet?  That's what's on the web page for the TM4C129DNCZAD.

Thank you!

-Dan

Hi Dan,

  I think I know the reason. I was reading the TM4C1294NCPDT datasheet which has internal PHY. I agree the datasheet description is a bit lacking in clarity when it talks about the PHY configuration. It is actually talking about the internal PHY configuration. TM4C129DNCZAD does not have internal PHY but rather MII/RMII interface. 

Charles -
Bummer your register screen shot was from the TM4C1294NCPDT datasheet and not the TM4C129DNCZAD datasheet, Dan and I were pretty excited! But an honest mix up, it happens.

Regardless, it did trigger me to try something different. Following the exact steps in section 23.4 of the ...DNCZAD datasheet, but using the register map from the ...4NCPDT datasheet (for the missing info). Redundantly I reprogrammed the bits needed (knowing full well that they probably already happened in the driver function calls prior), but in the interest of following TI's steps verbatim. Unfortunately the outcome was the same, proper PHY setup occurs on the MDC/MDIO lines, but no Ethernet data link.

In the interest of thoroughness I also compared it to the TM4C129XNCZAD datasheet, just to make sure nothing was different there either. Our hardware team has also scrutinized the design to make sure that all is correct, signals on the RMII connections were triple checked by another set of eyes, and all waveforms that should be present, were present (MDC, MDIO, RESET, RXD0, RXD1, RXDV, etc).

Pausing the debugger and looking at the registers also confirmed the code was actually programming the part registers per the steps in section 23.4, and all register bits were as expected/desired.

If you come across anything else that might trigger a breakthrough, let me know asap, but in the interest of project timeline we are going to have to explore other options.

Thanks,
-Kelly-

Hi Kelly,

  Sorry for the late reply. I'm on vacation. I will continue to search for posts that may help setup RMII interface.