GETCHAR() hanging on UART target custom board

[mci]

Hello,

I've used this snippet of code to prompt user for PWM x 10 values between 0-9 when I was evaluating on FRDM-KL28; first to vary the onboard RGB RED LED light like original SDK imported project, which I later modified & adapted to PWM a motor connected to an MCU GPIO pin out to J1 header on the eval board.

I'm using the J13 mini-USB to connect to the debug console, Hyperterm.  All UART RX/TX PRINTF have gone out on the terminal.  

I'm inside MCUXpresso debugging.

// code snippet

volatile uint8_t getCharValue = 0U;

 do 
 {
  PRINTF("\r\nPlease enter a value between 0 to 9 for low Duty Cycle to be multiplied by 10:\r\n");
  PRINTF("LOW VALUE DUTY CYCLE (0-9): ");
  getCharValue = GETCHAR() - 0x30U;
  PRINTF("%d", getCharValue);
  PRINTF("\r\n");
 } while (getCharValue > 9);

All GETCHAR() input works & the code does not hang on the GETCHAR() line - it does not hang & it waits & accepts keyboard inputs.

I'm now using our custom target board which does not have such mini-USB port but rather has a direct & plain vanilla UART RX/TX lines, custom connector on our board's side while the other side is a USB connector to interface still to the PC's Hyperterm console.

For the testing our custom board, I've made a different menu list that will prompt for a keyboard input just like how it did in that project on the FRDM-board.

I copy the same snippet of code but for a different & highly modified SDK imported project which operates on TSI touch buttons & a matrix of at least 30+ LEDS, to run on our custom board, still working inside MCUXpresso Multilink debugger.

On this board, with such snippet of code integrated into different application - the Hyperterm terminal displays the first 2 PRINTF() lines but then it hangs forever on the GETCHAR().  No key press on the hyperterm works to get it out of that GETCHAR() line.

I definitely have setup NEW UART RX & TX lines in correct ALT# function for UART, considering PRINTF()s are being dumped on the Hyperterm window afterall.

Does someone know what I need to do to make this menu keyboard input work?  The main differences between the FRDM-KL28Z & our custom board are:  

1) different UART port-pin #  (all checked & correct - PRINTF() is working)

2) different SDK modified code / different application

3) different cable, Layer 1 & 2 communications protocol: 

     FRDM-KL28Z was USB-to-USB serial UART

     Custom board UART-to-UART TX/RX

Thanks for your help.

MI

[mci]

   PS. When I got home late last night, CTS (clear to send) RS232 line occurred to me...CTS is active LOW.  That maybe, Hyperterm driver terminal emulator is looking for clear-to-send signal (low) from MCU thinking in UART protocol. So our current plain direct 9 pin UART to USB connector cable is not enough. We need an FTDI converter adapter cable that would ground/0V the CTS, so Hyperterm app's keyboard input willl go out to USB out to MCU UART? Is this thinking correct? Does it explain why my key presses on hyperterm seems to be ignored because it is not "clear-to-send" out to MCU RX uart line? No CTS low signal detected? Just floating high on our cable? Meaning NOT clear-to-send?  Please advise/confirm. Thanks.)

(NOTE: this is a copy of my response to you via email on Tech Support ticket, with slight typo corrections & paraphrase changes.)

Hello Kerry,

I’ve checked all but you can tell if I missed anything.

Our custom board (NOTE:  PRINTF() command is working well, it spews out what I want displayed on Hyperterm window)

// v3 5/30/19 mi debug console

// PORTA1 (pin 35) is configured as LPUART0_RX

PORT_SetPinMux(PORTA, 1U, kPORT_MuxAlt2);

// PORTA2 (pin 36) is configured as LPUART0_TX

PORT_SetPinMux(PORTA, 2U, kPORT_MuxAlt2);

We have plain-vanila, direct UART RX/TX to USB port.

On FRDM board:

I know that the as you stated, FRDM-KL28Z is PTB16 LPUART0_RX & PTB17 LPUART0_TX but that goes to “Arduino Headers” J1 connector pins

2 & 4 which are open - I don’t have anything attached there.

So how does that pinmux configuration of PTB16 & PTB17 relate?

Physically, my console port is connected to COM5 serial baud 115,200 via mini-USB on J13 which is connected to OpenSDA.

Last month, I talked with someone from PEMicro Multilink about moving out from MCU Debugger Console tab little window to do all debugging in Hyperterm window, outside of MCUXpresso, someone instructed me to install an openSDA dapboot loader driver code.

I just spoke again to the same person at PEMicro before I typed this post to clarify what that driver does.

He said that it is a UART emulator program that converts all debug console outputs (e.g. PRINTF()) & inputs (e.g. GETCHAR()) to communicate via the openSDA module through the J13 miniUSB port.

So that’s probably why HyperTerm is able to convert & transmit keyboard inputs out to the miniUSB, thru the openSDA & to the MCU KL28Z on FRDM board.

That explains how even though PTB16 & PTB17 are configured in pinmux.c as UART RX/TX GPIO function, they are actually UNUSED! Because everything is going through the openSDA to the MCU.

QUESTION:

Do you know which input pin from openSDA to the MCU does it go for the MCU to receive the keyboard entry through GETCHAR()? When I don’t see anything else setup in pinmux.c but PTB16 & PTB17 for UART on the imported SDK example?

ISSUE/BIG DIFFERENCE:

       I don’t have openSDA module on our custom board.

       Like I stated on original post, I assigned DIRECT UART TX/RX PTA2 & PTA1 for UART function & our HW engineer implemented it to our custom board.

       But now, even with correct pinmux.c setting, although PRINTF() is sending out strings to Hyperterm for displaying them, it seems that Hyperterm is not accepting keyboard inputs OR it maybe accepting & sending keyboard input & passing them through UART RX line to the MCU PTA1 but GETCHAR() is not accepting it?

       Do you know how I can fix this?

Thank you very much for the help.

MI

[kerryzhou]

Hi M I,

 Thank you for your updated information.
You have some misunderstanding about the opensda UART interface.
1. opensda for PTB16&PTB17 is just a TTL-USB tool on the FRDM-KL28.
   Even you don't have the opensda, you still can use the TTL-USB tool to connect it to PTB16 and PTB17. Please note, TTL-USB tool TX needs to connect MCU RX, TTL-USB tool RX needs to connect MCU TX.
  So, now, when you use your own board, do you have the TTL-USB cable?
  I think you have it.
  So, I suggest you test your tool on the FRDM-KL28 board directly, you can connect it to J1_2 and J1_4, then use your TTL-USB com port to test your working project for FRDM-KL28 instead of the on-board opensda com port.
  Whether the getchar works or not?

2. on your own board, with PTA1 and PTA2
  I suggest you test the UART code at first, don't use the getchar directly.
  Just check whether your UART driver code has problems or not.
  You can refer to the SDK uart code in the folder:
   SDK_2.5.0_FRDM-KL28Z\boards\frdmkl28z\driver_examples\lpuart\polling
  When you use the TTL-USB send the char to the UART port, can you receive it in the code?
  BTW, if you want to use the PTA1 and PTA2, you need to modify the pin_mux.c, add the PTA1 and PTA2 pin as the UART.
  If you can make the MCU PTA1 receive the data from your TTL-USB tool, then you can add or test your getchar code again.

Answer your question: the opensda pin is just the PTB16 and PTB17, which I have told you, opensda is just a ttl-usb tool. J1 is the pin fan out the interface, you also can test that pins directly.
You can find the PTB17 PTB17 pinmuc.c has configured the mux to ALT3, it is the LUART0 RX and TX function.
In your own board, you don't need the opensda module, you just need to use the TTL-USB tool, which is the same principle.
About the solutions for your question, in conclusion:
1) check ttl-usb tool send function works or not, you can check it on the frdm-kl28 board.
2) check your own customer code UART receive function have no problem
3) check your own customer board hardware UART connection have problems.

Wish it helps you!
If you still have questions about it, please kindly let me know.
If your question is solved, please tell me to close this case, and help me to fill the feedback as resolved, thank you and have a nice day.

Have a great day,
Kerry

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[kerryzhou]

Hi M I ,

Thank you for your interest in NXP kinetis product, I would like to provide service for you.
Please check these point at first:
1. UART pins
  FRDM-KL28 J13 is using the UART pins in the KL28 chip:
  PTB-16, UART0_RX
  PTB_17, UART0_TX
  What about your custom board? The same UART pin in the hardware?

2. You can use the Oscilloscope check the RX pins, when you send the data, whether the MCU RX pins have the wave or not?

3. What about the clock system, do you use the same clock system?
  When you send the UART with your own board, whether the baudrate is correct when you use the same code as FRDM-KL28?

Please double check it at first. Make sure the hardware signal is correct, if the hardware signal is correct, then you need to debug the code, check the code side.

Wish it helps you!
If you still have question about it, please kindly let me know.

Have a great day,
Kerry

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------