Serial interface loses sync

Go To Last Post
12 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Don't know if this is the right forum, but I have got a general question. What could go wrong if I am seeing an intermittent problem on a serial RS232 interface? The symptom is that it suddenly loses sync between transmitter and receiver. Could it be glitches on the communication lines?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, that's possible. But it's more likely that you're running the AVR from the internal RC-oscillator. If you didn't calibrate it, you'll run into comm errors. Simple solution: add a crystal and the two 20pF caps, and set the fuses accordingly.

A GIF is worth a thousend words   They are called Rosa, Sylvia, Tessa and Tina, You can find them https://www.linuxmint.com/

Dragon broken ? http://aplomb.nl/TechStuff/Dragon/Dragon.html for how-to-fix tips

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You can sometimes improve things, IF the timing is correct at each end, by changing the transmitter to two stop bits.

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Or increase the baud (say, from 9600 to 38400) and increase the delays - you'll still transmit the same (say, 960 bytes/second), but the delays between the bytes might improve the sync.

There are pointy haired bald people.
Time flies when you have a bad prescaler selected.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
changing the transmitter to two stop bits.

If you don't have gaps between your characters, it's the same as isochronous and the start bit detection doesn't always work. The extra stop bit gives the detector time to recover.

C. H.
-------------------------------------------------------------------
It's only waste if you don't use it!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the ideas. I will try the extra stop bit. How do I change the delays?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If the project will allow it from a data throughput perspective, try running at a slower baud rate and look at your error rate. It will often do better at the lower data transmission rate.

Please confirm, as mentioned above, that you are using crystals for timing at each end, (or at the micro end, if other is a PC, etc.), or are using a calibrated internal RC osc.

What is the error rate? Is it a function of temperature if you are using the internal RC osc?

Is your power supply clean on both ends, and is there a good ground connection between the two devices?

What is the length of the cable?

Any high power signals running near by, such as motor power lines, etc.?

Again, if the data rate allows it, it is sometimes easiest to use either an error detecting packet or an error correcting packet for your transmissions.

If you send a packet of data with a simple checksum you can easily tell if the packet has a single error in it, but you can not identify the error byte on the Rx end.

If your packet sends each data sub-packet three times, you can look for two of the three matching, and detect and correct for single errors without re-transmission. But the original transmission takes three times longer... but you say back and forth re-Tx requests, etc.

Checksums are simplistic and fast, CRC and other more advanced systems exist.

You are buffering the received data... I hope. Typically interrupt driven, Rx byte into a FIFO, Main reads out the data as needed. If you are not buffering then you need to process each byte quickly, before the next arrives. Any other interrupts lengthening your processing times now and then? Character padding is inserting a delay between each transmitted character to allow the receiving unit time to process that character and await the next one. (Without interrupts, and with slow processing, this is the "standard", think Basic Stamp I).

Hardware USART or bit banged?

Much depends upon the project, mission critical or not?

JC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Actually it was fixed with a simple reboot. The system was a PC serial port on one end and a part testing device on the other. This device has an entire communication module, so I did not open the module and see it. I guess something was "locked up" in the system. Thanks for the input JC. If it fails again I will use the techniques you suggested.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Darn!

I keep forgetting Rule #1...

If an MS Windows system is malfunctioning the first step is: Reboot!

Glad to hear you have it working, regardless the cause!

JC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Some hints .....

IF something should trigger false recognition of a start bit, then the UART will run for the full defined character length. It will probably (but not assured) report a bad stop bit. But, the important thing is that it MAY be ready for the next start bit in the middle of an actual character. It could well detect one of the internal character bits (incorrectly) as a start bit. If things just happen to line up, this can persist for some time. It will be "unlocked" only if there is a pause greater than 1 character in length. This will for the next synchronization event to be the next start bit (unless new noise happens to come along).

One of the other strategies is used if a bad stop bit is detected. Then, simply wait more than the usual stop-bit time before re-enabling the receive. This will at least shift the sync point within the sequence of characters and it might recover sooner than just waiting for a long pause.

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ok thanks Jim that helps. This may be a stupid question but can you dynamically change the number of stop bits between different frames? Like maybe have more stop bits for better error detection on power up and then lower the stop bits as you get more frames which are in "sync". And everytime you get a bad frame, increase the stop bits and reduce them when you get a fixed number of "healthy" frames.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sure.

More than two requires a timer, so you can make that any duration you wish. Since a timer is needed for more than two, I use the UART for one and the timer for any more than that.

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net