cancel
Showing results for 
Search instead for 
Did you mean: 

Unwanted bytes with UART in master and slave MCU

Davood_Kesha
Associate III

Hello St Teams,

I have two MCUs (one as master and other as slave). They can send and receive data through UART (UART+DMA). The master/slave is always listening. Whenever, the slave receives command from the master, it sends data back to the master. The DMA is interrupted after receiving specified length of data in both MCUs. In the code, I check the first and the last byte to see everything works correctly. But the problem arises when I want to connect two MCUs via cable. At this time, the MCUs receive unwanted bytes due to glitching.
How I can make the whole system robust to unwanted bytes when the data length is fixed? What strategy would you suggest?

Best,
Davood. 

4 REPLIES 4
Andrew Neil
Super User

@Davood_Kesha wrote:

But the problem arises when I want to connect two MCUs via cable. . 


How long is this cable?

Does it include a GND?

 

Note that UART alone is not suitable for long cables - you should add something like RS232, RS422, etc ...

A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.

Actually I am using RS485 ICs and the GND is good. 
My problem is how to make system robust against incorrect bytes???
The master controller is sending command regularly (it does not matter if the cable is connected or not).
Sometimes when I connect the cable, the received data by the slave is not complete. Since the slave DMA is configured for a specified length, it cannot be modified in the next transmissions. Then I cannot consider the first and last bytes.

 


@Davood_Kesha wrote:

Actually I am using RS485 ICs and the GND is good. 


This is why it's always best to provide a schematic!

 How to write your question to maximize your chances to find a solution 

 


@Davood_Kesha wrote:

My problem is how to make system robust against incorrect bytes???


First thing would be to determine where these "extra bytes" are coming from.

The whole point of RS485 is that it should have very good noise immunity - so, if you're getting noise, there must be something bad in your design.

Have you used an oscilloscope to see what's actually happening on the wires?

Having used an oscilloscope to verify that the signals are good and clean, then use an analyser to see what's actually being sent and received.

Have you tested against known-good devices; eg, a PC terminal?

Have you tried without DMA?

Are you handling UART errors (framing, overrun, etc) ?

 

Debugging Serial Comms

 


@Davood_Kesha wrote:

 how to make system robust against incorrect bytes???


Use an error detecting/correcting protocol

 


@Davood_Kesha wrote:

Since the slave DMA is configured for a specified length, it cannot be modified


Clearly, that's inherently fragile!

A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.

Use DMA in circular mode with idle interrupt. If using normal mode, it is very limiting and you can get out of sync.

 

If you have a fixed packet size, you'll need at least a CRC for the last byte. 

You'll need to create a circular buffer for the received DMA data. During Half, Complete or Idle interrupt, save the data to the circular buffer. As more data is received, you continue to add to the circular buffer.

Since you know the fixed length of the packet, you can parse through the circular buffer and calculate the CRC for the n amount of packet bytes minus the CRC byte. Then compare result to the CRC byte. 

If you've got a good CRC, then process the data or save the good packet in a queue for later processing in main while loop.

If bad CRC, then shift out the first byte. Wait until you get another byte and then recalculate the packet CRC. Repeat until you get a good packet.

If a reply has proven helpful, click on Accept as Solution so that it'll show at top of the post.
CAN Jammer an open source CAN bus hacking tool
CANableV3 Open Source