A lot of frame errors

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

Hi there,

I have a lot of frame errors in an RS-485 protocol.

All of my terminals is been clocked by a 7.3728 crystal and the comunication setup is 115200bps, 8, n, 1.

There is a master that polls 2 slaves, one by one each 100ms.

Why is this heppen and what can I do?

Michael.

Michael.

User of:
IAR Embedded Workbench C/C++ Compiler
Altium Designer

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

1. Use twisted pair and terminal resistors.
2. Look at the line with oscilloscope:
- What kind of noise is there?
- Master could still stand on-line during a slave starts to answer or something like that.
3. Make an experiment setting 2 stop bits.

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

Random guess here.

I assume that the RS 485 receivers need to be enabled to allow them to transmit and disabled afterwards?

It is not that you are disabling the transmitter devices when you load a character into the USART rather than waiting for the character transmission to complete, is it?

A

If we are not supposed to eat animals, why are they made out of meat?

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

Quote:

It is not that you are disabling the transmitter devices when you load a character into the USART rather than waiting for the character transmission to complete, is it?

...or using UDRE instead of TXC? (there are opinions on this but I use TXC exclusively on my '485 apps and have no framing errors)

Do you have the proper pulling and load resistors?

What does a 'scope show? Note that you look at each line individually, but to really see the waveform you have to go across the lines. That signal should go above and below the "line". It isn't uncommon to "blow" just one driver in a transceiver chip and then the signal doesn't go both above and below the "line", and it kinda works, but ...

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

A frame error occurs when it does not receive a valid stop bit.

My experience has been that this mostly occurs when you enable the receive too late and the UART detects some bit inside the character as the start bit. Another cause might be switching transceiver directions at the wrong time.

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

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

Quote:
1. Use twisted pair and terminal resistors.
2. Look at the line with oscilloscope:
- What kind of noise is there?
- Master could still stand on-line during a slave starts to answer or something like that.
3. Make an experiment setting 2 stop bits.

There is no twisted pair because the system is on my desk with approx 30 mm cables. There are 120Ohm resistors at the 2 line end terminals. Also there is no noise there. Tomorrow morning I will test the 2 stop bits idea.

Quote:
I assume that the RS 485 receivers need to be enabled to allow them to transmit and disabled afterwards?

This is correct and viewing it by the scope it looks realy fine.

Quote:
...or using UDRE instead of TXC? (there are opinions on this but I use TXC exclusively on my '485 apps and have no framing errors)

I also use the TXC interrupt for transmiting any new data in a transmit buffer. Also I use the RXC interrupt to store any new data in a receive buffer.

Quote:
Do you have the proper pulling and load resistors?

I don't have the ic code right now but I will post it tomorrow. It is from texas instruments and as I red there is no need for ext. pull-up-down resistors at the RS-485 lines.

Quote:
What does a 'scope show? Note that you look at each line individually, but to really see the waveform you have to go across the lines. That signal should go above and below the "line". It isn't uncommon to "blow" just one driver in a transceiver chip and then the signal doesn't go both above and below the "line", and it kinda works, but ...

I will check this more carefully.

Quote:
My experience has been that this mostly occurs when you enable the receive too late and the UART detects some bit inside the character as the start bit. Another cause might be switching transceiver directions at the wrong time.

I believe that there is no posibility of this because the master polls a slave then the slave answers imidiately and after 100ms the master calls the second slave and so on. But I will check it again.

Tha truth is that while debuging I have the 2 probes at the 485 lines and 3rd - 4th at the receivers DE pins (RS-485 transmit enable pin).

Thank you guys.

Michael.

Michael.

User of:
IAR Embedded Workbench C/C++ Compiler
Altium Designer

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

Quote:

It is from texas instruments and as I red there is no need for ext. pull-up-down resistors at the RS-485 lines.

Perhaps OK for your short run. We have fairly strong resistors on our designs.

In your mentions of TXC, I don't see anything about turning off TE after the last character gets into the TXC ISR. Are you?

Now, that may be serviced a bit time or so after the slave has gotten the last character. If it immediately starts to send its response there could be a race. Try having the slave delay for a ms or so before responding, just to see if the symptoms change.

[Hmmm--you should be able to see that on the 'scope, too. In our "real" apps no two transceivers are ever exactly the same so you can see a slight amplitude difference between the poll and the response. That may not occur with your short run and no pulling resistors.]

So you are seeing nice square edges on all of your signals? And it goes above and below the "line"? (I float the TDS 'scope, put "ground" on line line and the probe on the other.)

Try an easy character like 'U' at 8-n-1, and the same response from the slave. One 'scope picture of that should tell the tale.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

I found it,

I use a test program (written in VB6) in order to simulate the master terminal. The problem is that unfortunately the PC, sometimes, holds the RTS signal (which I use for controlling a 232 - 485 converter's DE pin) more time that I have programmed. This is because the VB6 timming is based on the PC tick, and there is also a .pdf telling you that in any case you have to wait at least 20ms, for an unoqupied line.

I hope that when I will get the pcb of the real terminal in my hands, this will not be happens any more.

Thank you all,

Michael.

Michael.

User of:
IAR Embedded Workbench C/C++ Compiler
Altium Designer