AnsweredAssumed Answered

Trouble using printf/debug_printf using MQX/KSDK/PEx with FRDM-K22F

Question asked by dave408 on Apr 9, 2015
Latest reply on Apr 21, 2015 by dave408

I still haven't got a good understanding of how determining what pins are used for the UART that eventually sends its data to the virtual COM port when using the Segger jlink firmware.

 

I have a bare metal project where printf goes to the console window in KDS, which is pretty nice.

 

I have a FRDM-K64F project that connects fsl_debug_console to UART0, and output from debug_printf goes to the virtual COM port.  I have to open a terminal program to see the output, but that's fine.  Rx goes to UART1_RX_TGTMCU and Tx goes to UART1_TX_TGTMCU.  The issue for me here is that I wouldn't have known how to determine those are the right pins, if I hadn't read someone else's tutorial. 

 

I have a FRDM-K22F project that connects fsl_debug_console to UART0, and I have assigned Tx to PTB17, but none of the options are free or make sense.  For example, here are the available options:

  • PTB17 - available, assigned, but not working with debug_printf
  • PTA2/UART0_TX/FTM0_CH7/JTAG_TDO/TRACE_SWO/EZP_DO - in conflict
  • PTD7/UART0_TX/FTM0_CH7/FTM0_FLT1/SPI1_SIN - in conflict with SPI

 

Rx has no available options:

  • PTB16 - in use, but if it's the one that *must* be used, that's fine, I can change to another GPIO
  • CMP0_Output - not available with the CPU package
  • CMP1_Output - also not available
  • PTD6 - in conflict with SPI
  • PTA1/UART0_RX/FTM0_CH6/JTAG_TDI/ESP_DI - in conflict with other property, though it's not one that I set up

 

So how does one determine what pins should be assigned to the UART that will go to the virtual COM port or the console window?

 

At this point, I really only need Tx working so I can output to the terminal, but I can't even get that to work when set to PTB17, which is the only available option...

Outcomes