UART Error checking

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
CaDu_3933941
Level 4
Level 4
50 replies posted 25 replies posted 10 replies posted

Hi all,

I have been working UART communication via radio between PSoCs. I want to be able to detect errors during communication for which I have been recommended to use some sort of checksum. Below is the scheme I am using to send the data.

Start Byte, Byte 1, Byte 2, ....., Byte N, chksum, CR

Now, I just want to understand how the cheksum would work. I understand that the receiver would also send the calculated cheksum back and should they match, I would have no error, and if they don't I would have an error.

The one thing I don't understand is how would the transmitter know if there was an error. Does the receiver send an acknowledge signal? How does the receiver know which byte is the cheksum byte? What if the cheksum did match and the receiver sent back an ack signal, however the message got lost along the way signifying an error eventhough there was not one?

0 Likes
1 Solution
lock attach
Attachments are accessible only for community members.
MotooTanaka
Level 9
Level 9
Distributor - Marubun (Japan)
First comment on blog Beta tester First comment on KBA

Hi,

So I reviewed my sample code ant noticed that

in my previous sample, receiver was sending back "OK\r" when it receives a correct packet.

But at that time I could not make the transmitter receive the response from the receiver.

After spending whole this morning, I noticed that you are connecting a DAC to TX_1 of UART in the receiver,

which was preventing my transmitter from receiving a response from the receiver, when they are directly connected using jumper wire.

001-org-tx1.JPG

So, for the time being I changed the pin to a normal pin.

Note: Your system may have worked without modifying this part.

002-modified-tx1.JPG

And I needed to add "receive_ack()" function.

BTW, currently I'm setting the timeout for 1sec (1000ms) may be you want to make it much shorter.

So now my sample(s) of the day can confirm that the data was correctly received by the receiver or not.

003-tx.JPG004-rx.JPG

moto

View solution in original post

0 Likes
4 Replies
MotooTanaka
Level 9
Level 9
Distributor - Marubun (Japan)
First comment on blog Beta tester First comment on KBA

Hi,

I'm afraid that I was the one who suggested this scheme.

But in my sample transmitter was not checking the response from the receiver.

So in my sample, the transmitter did not care if the data was received correctly or not. (just like UDP)

If you want to make sure that the data was received right,

you need to receive the ack packet from the receiver and check it against the packet you sent.

(At that time I thought that the sample was enough complicated without doing this)

Since transmitter has calculated checksum for the sending packet comparing it with the received data might be good enough.

Meantime what the receiver in my sample did were

(1) using a ring buffer and always searching for CR.

(2) If CR is detected, check if the letter in current index - (N+4)  was 's', -(N+3) char was 't', and -(N+2) char was 'r'.

If this matches, at least the receiver received a packet

['s']['t']['r'][data1]...[dataN][checksum][CR]

(3) Then the receiver calculated checksum as LSB Byte of sum of  ['s'] to [data10]

(4) In case checksum matches with the calculated sum the receiver accept that the packet is a correct packet and used the data

     if any of (2) ~ (3) fails, the receiver just gave up and resume the searching for CR

moto

0 Likes
lock attach
Attachments are accessible only for community members.
MotooTanaka
Level 9
Level 9
Distributor - Marubun (Japan)
First comment on blog Beta tester First comment on KBA

Hi,

So I reviewed my sample code ant noticed that

in my previous sample, receiver was sending back "OK\r" when it receives a correct packet.

But at that time I could not make the transmitter receive the response from the receiver.

After spending whole this morning, I noticed that you are connecting a DAC to TX_1 of UART in the receiver,

which was preventing my transmitter from receiving a response from the receiver, when they are directly connected using jumper wire.

001-org-tx1.JPG

So, for the time being I changed the pin to a normal pin.

Note: Your system may have worked without modifying this part.

002-modified-tx1.JPG

And I needed to add "receive_ack()" function.

BTW, currently I'm setting the timeout for 1sec (1000ms) may be you want to make it much shorter.

So now my sample(s) of the day can confirm that the data was correctly received by the receiver or not.

003-tx.JPG004-rx.JPG

moto

0 Likes

Motoo,

The DAC's output was set to 3.3V in order to drive the output of the UART high logic level from 5V to 3.3V since that is the logic level required for the radio module I am using.

One thing I noticed in the scheme you provided for me is that you added a delay on the receiver side. The problem with this is that the receiver is an RC car in which case, I would need to avoid any delays. Any chance the delay could be replaced with a timer?

0 Likes
lock attach
Attachments are accessible only for community members.
MotooTanaka
Level 9
Level 9
Distributor - Marubun (Japan)
First comment on blog Beta tester First comment on KBA

Dear CaDu-san,

> The DAC's output was set to 3.3V in order to drive the output of the UART high logic level from 5V to 3.3V

> since that is the logic level required for the radio module I am using.

That was what I was assuming, in my side, I'm testing with a couple of CY8CKIT-059s connected together with jumper wires.

So this voltage shift prevented my setup to receive data from Receiver to Transmitter.

As I wrote, if your system is working fine, you don't have to change the schematic for your side.

> One thing I noticed in the scheme you provided for me is that you added a delay on the receiver side.

> The problem with this is that the receiver is an RC car in which case,

> I would need to avoid any delays. Any chance the delay could be replaced with a timer?

If you are talking about delay here,

===============

            UART_Jetson_PutString(str_buf) ;

            CyDelay(10) ;

           

            UART_PutString("OK\n") ; /* send ACK */

===============

The delay was added during my struggle with making the transmitter to receive the response from the Receiver.

So it can be removed or commented out.

===============

            UART_Jetson_PutString(str_buf) ;

//            CyDelay(10) ;

           

            UART_PutString("OK\n") ; /* send ACK */

===============

Attached is the receiver without the delay.

Transmitter

001-Transmitter.JPG

Receiver (without the delay)

000-Receiver.JPG

Best Regards,

22-Jun-2020

Motoo Tanaka

0 Likes