A problem connecting the KMS to a custom hardware

Showing results for 
Search instead for 
Did you mean: 

A problem connecting the KMS to a custom hardware

Contributor II

Hello, I have a problem connecting the KMS to a custom hardware.

I'm working on a Windows 10(32 bit) machine, using the MCUXpresso v10.1.0 and KMS 1.2.0.
I do the flash programming and debugging using a SEGGER j-link debug probe.

My control board incorporates a 64-pin MKV31F128VLHP MCU.
(the device is really KMS-enabled, at least each attempt to read the highest 8 kbytes results in an error)
My serial communication interface uses UART1(PTE0, PTE1) pins instead of (default) UART0.

I created a KMS-project, selecting a PMSM motor, KV3x family, High Voltage platform, Sensorless Velocity control, MCUXpresso IDE.
Then I followed all the relevant steps depicted in AN5254 "Adapting KMS for Custom Hardware.pdf" Rev. 3, 11/2017:
- created an SDK for the MKV31F128xxx10 and added it to the IDE
- changed the MCU Part Number as described
- in "kms_hw.h" changed UART0 to UART1
- in "pin_mux.h" changed the UART-pins definitions to correspond to the actually used ones(pins 1 and 2 - PTE0, PTE1) for UART1

Then I tried to connect the KMS to the MCU board. This did not succeed.
I received the following message from KMS:
An issue has prevented communication with target
MCU: The ping message was not acknowledged.
Please check physical connection to MCU, then
navigate to Project menu to configure communication

Further, I looked inside "main.c" and found there some calls and function declarations/definitions, explicitly referring to UART0:
- FAST void UART0_RX_TX_IRQHandler(void) which overwrites the WEAK void UART0_RX_TX_IRQHandler(void)
- void UART0_ERR_IRQHandler(void)
- NVIC_SetPriority(UART0_RX_TX_IRQn, 15);
- NVIC_SetPriority(UART0_ERR_IRQn, 15);

So, I changed 'UART0' with 'UART1' in all these instances.
Now, when trying a connection with KMS, I started receiving interrupts on UART1,

but still no reply from the MCU followed.
The above message still appeared.

I stopped the program on a breakpoint and looked at the contents of the UART buffer "uart_rx_buf[]".
Each time a connection was tried, there were 20 bytes collected in uart_rx_buf[], looking like that:
27, 2, 36, 2, 0, 17, 2, 180, 27, 3, 27, 36, 0, 2, 0, 17, 2, 180, 27, 3.

The "uart_rx_head" and "uart_rx_tail" values wee both equal to 20.
However, the "uart_tx_head" and "uart_tx_tail" values stayed 0.

So, what I see is that the Remote Debug Agent invokes the "uart_rx_byte()" method
and fills the "uart_rx_buf[]", but "uart_tx_byte()" is never called.
I verified that by setting the optimization level to "O0" for the "rda_uart_kv3" module and adding a breakpoint inside uart_tx_byte().
The breakpoint was never hit.

So, as far as I can tell, all hardware-related communication problems are fixed, the RDA receives data from the KMS but it still does not answer to a ping.

Can you, please give me an advice in this situation? What shall I do to make the MCU reply?

Labels (1)
0 Kudos
4 Replies

NXP Employee
NXP Employee

You have made all the necessary changes in the code.  Reducing the baud rate is a good suggestion.

I performed the UART0 to UART1 changes to a FRDM-KV31 and made all of the same changes you did in the code.

  1. in kms_hw.h
    * @def KMS_UART
    * @brief UART Instance used by KMS
    #define KMS_UART (UART1)
    * @brief Default baud rate for KMS UART communication
    #define KMS_UART_BAUDRATE (57600u)
  2. In main The first step I took was to duplicate all of the UART0 interrupt handler and change to UART1. You can go back and remove the UART0 instances once all is working.
  3. in the NVIC_Enable calls I did the same and simply added UART1 calls.

I used the MCUXpresso pins tool to add the PTE0 and PTE1 UART pin mux initializations. without removing UART0.

One thing I also did during debug is used a terminal program (like Putty) to verify my UART hardware connections.  I set up the terminal interface, tied TX to RX and held down the upper case U.  If you do this then you should see the U echoed back to the terminal.  I also put a scope on the looped back hardware pins to verify the signal. 

Once that was verified I closed putty and was able to connect the KMS GUI to UART1_TX and UART1_RX on PTE0 and PTE1 with no problems at 57600. 

Contributor II

Thanks for the helpful response and the test you have done, Philip.

As you may have noticed in the reply to the first comment to my post, the problem appeared to be in the communication speed, too high for a port without a FIFO and served from the backgound. And, of course, preserving the UART0-related calls and definitions was not really needed, just the baudrate reduction.

For the time being, I've established connection between the KMS and the control board, now the harder part of the adaptation work lies ahead.

Thanks once more and have a good day!

0 Kudos

Senior Contributor I


There is a key difference between UART0 and UART1 on the KV31 microcontrollers.  UART0 has a much deeper FIFO as compared to the other UARTs.  (Section of the KV31F128 Ref Manual)

Take a look at the variable uartRxOverRunCounts in the watch window or debugger.  My guess is that you are getting a lot of these errors and are triggering the UART1_ERR_IRQHandler.

There are a couple options:

1. reduce the baud rate for serial communications (KMS_UART_BAUDRATE in ksm_hw.h)

2. adjust the ISR priority for UART1

3. setup the DMA so that it will handle buffering the incoming data over the serial link

4. modify the hardware to use UART0

Contributor II

Many thanks for the prompt reply, Adam! I really appreciate it.

I was aware of the difference between UART0 and UART1 (the absence of a FIFO in the latter), but I didn't assess the impact of it in the particular case. The problem was really solved by reducing the UART1 baud rate (as suggested), this obviously follows from the fact that the RDA performs as a background task.

In my board design, UART1 was preferred over UART0 solely because it is the uart-interface used by the Kinetis Flashloader. Actually, the board was intended for other purposes(not KMS), but I found it appropriate for assessing the LineStream software.

One small note: in "flash_config.c" un-commenting the "#define KMS_MASS_ERASE_DISABLED" line(as recommended), combined with changing the part type to CPU_MKV31F128VLxx, produces a building error due to redundant braces in lines 67, 68.

Thanks once more and have a good day! 

0 Kudos