UART data corruption at RX end

cancel
Showing results for 
Search instead for 
Did you mean: 

UART data corruption at RX end

Jump to solution
734 Views
kbhat
Contributor II

Hi All,

I'm using a MK10FX512VLQ microcontroller for development. Firmware sends data packets to a Windows PC Application through UART. At a specific data packet which is of 9 bytes that is being sent from the firmware via UART to PC app, the data is getting corrupted with the last 3 bytes being overwritten to zero. When the Firmware sends the same data packet to Docklight, the data packet is sent intact without any corruption. But when the same data packet is sent to the PC App, the PC App is receiving a corrupted data. Have tried several methods to debug this issue. But couldn't find a solution.  Please suggest solution.

Awaiting replies.

Thanks,

Krithika

Labels (1)
0 Kudos
1 Solution
716 Views
myke_predko
Senior Contributor III

@kbhat ,

If the data is correct when you look at it in docklight, why wouldn't you assume the problem is in your PC application?  

If I understand the flow correctly:

  1. Firmware is sending 9 byte packet
  2. PC Software is acknowledging receipt of the packet 
  3. When PC Software is processing the the 9 byte packet it becomes apparent that the last three bytes are zeros  

Is therre a checkbyte in your packet that ensures the data is correct (and generates the ack in the PC Software)?  

myke

View solution in original post

6 Replies
731 Views
bobpaddock
Senior Contributor III

Check the baud rate and frame format.
Docklight might be more forgiving about miss-matches than PC.

 

0 Kudos
728 Views
kbhat
Contributor II

Hi,

The baud rate & frame format is correct. The other data packets are being received properly by the PC App and giving an ACK to firmware. But a specific data packet is getting corrupted.

0 Kudos
717 Views
myke_predko
Senior Contributor III

@kbhat ,

If the data is correct when you look at it in docklight, why wouldn't you assume the problem is in your PC application?  

If I understand the flow correctly:

  1. Firmware is sending 9 byte packet
  2. PC Software is acknowledging receipt of the packet 
  3. When PC Software is processing the the 9 byte packet it becomes apparent that the last three bytes are zeros  

Is therre a checkbyte in your packet that ensures the data is correct (and generates the ack in the PC Software)?  

myke

View solution in original post

685 Views
kbhat
Contributor II

Hi Myke,

Thanks for the suggestion. The sequence of FW - PC App that you mentioned is correct. The issue was at the PC App. We added a small delay of 25ms at the serial port read method of the PC App & the issue got resolved. 

Thanks for the support.

Regards,

Krithika

677 Views
myke_predko
Senior Contributor III

@kbhat 

That's great you found your problem.  

Good work!

myke

0 Kudos
675 Views
kbhat
Contributor II

Thank you.

Krithika

0 Kudos