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;
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;
} 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.