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.