Possible conflict between ENET and UART3 on K64?

[dave408]

I have some prototype hardware that I currently have running on an FRDM-K64F, programmed using the mbed environment.  As you can see below, the FRDM-K64F shows that UART3 is using PTC16 and PTC17.  Obviously, there's also ethernet available, which I use.

Now I want to move away from mbed and have been evaluating bits and pieces of KDS/KSDK/MQX/RTCS for the past month.  I want to ensure that I can get my prototype running this toolchain on the FRDM-K64F before I move on to a custom PCB.  I am looking over the datasheet for the K64F processor to reconcile all of the pins used, and possibly pins I'll want to add to the new PCB.

My question here is related to pin_mux.c, which provides several helper functions for configuring the peripherals on the K64F.  Specifically, configure_enet_pins sets up several pins, two of which are PTC16 and PTC17 (as ENET0_1588_TMR0 and ENET0_1588_TMR1).  So it would seem that there's an inherent conflict between using ethernet and UART3, but the mbed docs clearly show that UART3 is on those same pins!

What's really interesting is that pin_mux.c does not have a case in configure_uart_pins that handles HW_UART3, so it almost seems that the KSDK team is aware that there might be a conflict.  I ended up adding a case for UART3, but this might be a problem.  Or is this actually just an oversight in the KSDK?  I am still learning how to use the UART, so I haven't been able to write any test code yet.  However, after configure_enet_pins is called by _bsp_pre_init, my main task calls configure_uart_pins( 3), which I imagine will prevent ethernet from working properly.

Any insight into this would be really appreciated!  Thanks.

[apanecatl]

Well if you check out k64's datasheet you will notice UART3 is routed to multiple pins, not just PTE16 and 17, and what you mentioned is true; you cannot use both UART3 and ENET at the same time if they share pins. My suggestion is: use another UART port if possible or use a different pin mux for UART3.

[dave408]

Hi Pedro, thank you for your response.  Let me explain a little more of my thought process so you can tell me where I went wrong.  While UART3 uses PTC16 and PTC17 according to the FRDM-K64F design, I noticed that those pins are used for ENET0_1588_TMR0 and ENET0_1588_TMR1.  Yes, there is another location for the ENET0* pins, and the ones in question are PTB2 and PTB3.  The K64F design has those allocated for analog inputs already.

If the K64F has working ethernet, UART3, and analog inputs, it doesn't seem possible for the ENET0 to be used by the ethernet module because there is no set of pins available for them.  I don't know what those pins do, but since the KSDK configures them, I can only assume that they are required.

Can you please clarify this for me?

[dave408]

Since it was easy enough to do, I modified my existing application to use UART3 configured on PTC16 and PTC17, in addition to ENET0_1588_TMR0 and ENET0_1588_TMR0.

I modified configure_uart_pins in pin_mux_c by adding a case for HW_UART3, like so:

I also confirmed that configure_enet_pins was being called before configure_uart_pins(3).

I am able to connect to my K64F via ethernet, as well as execute my loopback tests on UART3.

Any information about what ENET0_1588_TMR* is all about would be appreciated.  I can't find anything about it online.  I only found this in the sub-family manual, which makes it sound important, but I don't know if it's actually required to get ethernet functional.

[dave408]

Yay, I spoke with my colleague who knew offhand what ENET0_1588_TMR0 is related to.  My google-fu failed me, but he told me right away that it has something to do with precision timing over ethernet.  Looking at a random datasheet for a chip that is IEEE 1588 compliant, it sure sounds like this functionality is *not* required to get ethernet working on the K64F.

Therefore, my conclusion is that the KSDK is slightly misleading in that:

1.  in configure_enet_pins(), it sets up the ENET functionality for PTC16-19 and

2.  in configure_uart_pins(), a case for HW_UART3 is conspicuously missing

which implies that the FRDM-K64F is wired this way, yet none of the ENET pins are routed to the ethernet page in the schematics.

Phew!  I'm glad that there is finally an explanation of what's going on.  I'll just remove those function calls from configure_enet_pins and continue on with development.

[apanecatl]

You're right, the ENET0_1588TMRn registers are related to a function called timestamp, it latches a specific time to an specific event triggered by the Ethernet module, however that function is optional, it does not need to be active for the Ethernet to work correctly. And I partially agree with you on the misleading, though I would rather mention it as confusing.

[dave408]

I'm okay with "confusing".  :smileyhappy:  Thanks for confirming the "optionality" of using ENET 1588!