LPC1769 UART problem

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

LPC1769 UART problem

409 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by karanmehta93 on Wed Jan 01 15:27:33 MST 2014
I am using UART to receive two bytes at a time with a LPC1769 from Atmega8. The UART starts with an falling edge interrupt generated in LPC1769 by using a GPIO pin of Atmega8. Since the two bytes are required in order, the code remains inside a loop until the whole byte is received and then copies it into a variable name "val1". It does the same thing again for variable "val2".
However during the course of time, I find that sometimes, unusually, the bytes val1 and val2 get interchanged. It severely affects my program.
Since I am controlling motors also along with this, the spikes of motor can be a reason for that.
I wanted to know the possible reasons for the bytes getting interchanged even when UART is used with interrupt.
Also suggest me possible methods to avoid the same problem again.
Labels (1)
0 Kudos
2 Replies

331 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by karanmehta93 on Mon Jan 20 07:20:09 MST 2014
I have done this by sending 3 bytes instead of 2, out of which 1 is constant and is known to both tx and rx. Still then, the problem persisted and hence I have kept cyclic movement between the values received. Will you please elaborate on framing error?
0 Kudos

331 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by triffid_hunter on Sat Jan 18 02:22:40 MST 2014
if the second byte gets corrupted, then the UART will flag a framing error or similar. Then your code waits to receive a second byte, and instead eats the first byte of the next packet.

You want to establish a protocol- perhaps a preamble byte, your data payload, then a checksum byte.

Since you never know which bytes could be lost, or whether you're receiving junk bytes, you must keep checking for new preamble bytes, and only accept valid frames with correct checksum

uarts and similar should always be hooked up to a ringbuffer, then you can drain the buffer from mainloop and crunch data there.
0 Kudos