RS485 Framing Error when toggling RE pin

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

I've gone through a bunch of the "RS485 and framing errors" posts on this forum, and I believe this is a unique case. I'm using a ISL81487EIBZ-T transceiver (datasheet) and every time I disable RE (bringing the pin low), I receive a receive a framing error as input on the AVR RX line (the AVR interprets this unexpected input as 0x00).

 

Originally I wrote this with straight AVR GCC C++ and was using TXC0 to ensure that all the data had been sent before toggling the RE pin. But just to make sure I wasn't doing something stupid, I built a simple Arduino sketch with delays before and after sending data, and it still occurs. 

 

Here's the simplified sketch:

void setup() {
  pinMode(2, OUTPUT);
  pinMode(A5, OUTPUT);
  Serial.begin(9600);
}

void loop() {
  delay(250);
  digitalWrite(A5, HIGH); // RE
  digitalWrite(2, HIGH);  // DE
  delay(250);

  Serial.print("H");
  Serial.flush();

  delay(250);
  digitalWrite(2, LOW);  // RE
  digitalWrite(A5, LOW); // DE
}

Here's the output captured with my Saleae Logic analyzer connected to the AVR RX and TX pins:

 

 

As you can see that the data sent was completely finished by the time the RE pin was toggled. It's interesting that enabling RE causes the RO line to go high and then low when it's disabled; which in turn returns a framing error. Is this expected?

 

My circuit is simple and follows the datasheet. I have DI connected to TX, RO connected to RX, a decoupling cap between power and ground and a 120 ohm terminating resistor. In this example, the transceiver is the only device on the bus. (The entire bus is a 12 inch twisted pair from the transceiver to the terminating resistor) 

 

I have an oscilloscope, but not entirely sure how to use it to debug this (I just recently purchased it and still learning how to use it, any guidance for this case would be appreciated).

Last Edited: Wed. Jun 15, 2016 - 06:32 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Another interesting thing. If I just toggle the RO pin but never send any data, this doesn't occur. It only seems to happen after I send data, even if the pin is toggled long after it was sent. 

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

Put a 10K pull-up resistor on the Rx input pin to the uC.

 

When the RS485 receiver is disabled, the Rx input on the uC floats.

 

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

Is you RS485 bus properly terminated?

John Samperi

Ampertronics Pty. Ltd.

https://www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Chuck99 wrote:

Put a 10K pull-up resistor on the Rx input pin to the uC.

 

When the RS485 receiver is disabled, the Rx input on the uC floats.

 

 

+1 or, even easier, enable the internal pull-up on the RxD pin.

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

schtevo wrote:
+1 or, even easier, enable the internal pull-up on the RxD pin.

That's what we do.

 

Now, you didn't really describe all the connections.  We've done all of our dozens of production RS485 apps with TE-/RE tied together -- i.e., I don't listen to what I send.  There are others here (js?) that listen to what they send and compare, to look for collisions.  Which camp are you in?

 

Yes, you can get spurious characters, usually/often framing errors.  My "engine" just discards them when not expected, but in any case with the internal pullup enabled on the RX line you will get very few if any IME.

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

theusch wrote:

Now, you didn't really describe all the connections.

 

Originally I had both DE and RE tied together, using one pin to toggle them both. Then, to isolate what was happening, I put them on different pins. The framing errors were happening in both cases.

 

I do not have any pull-downs on RX or TX. I'll try adding one to RX next.

 

The problem my code has with discarding the framing errors is that, in some cases, they occur right before the AVR is expected to receive input from the slave nodes on the bus. I'm guessing that there's no good way, outside of the slaves sending an expected byte first, to detect when the data is from a framing error? Do you have a standard communication protocol that you use for your RS485 projects?

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

jgillick wrote:
The framing errors were happening in both cases.

Yes, it will.  maybe.  Depending on how RXD drifts.

 

jgillick wrote:
I do not have any pull-downs on RX or TX. I'll try adding one to RX next.

No-one in the thread mentioned pull-downs...

 

schtevo wrote:
enable the internal pull-up on the RxD pin.

 

 

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

theusch wrote:

schtevo wrote:
enable the internal pull-up on the RxD pin.

 

Sorry, I misspoke. Yes, the internal pull-up.

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

If all drivers on a RS485 bus are disabled and you only have the termination resistors there is no differential voltage on the bus, which is not a valid signals state.

Generating a few ten's of mV offset on the bus (pullup to Vcc, pulldown to Gnd) make's it a valid state and will prevent the receivers from detecting bit changes during turn on/of of a driver.

This is described in several RS485 AN's.

 

Logic analyzers are not very usefull for this. Use your scope to measure the differential voltage on the bus itself.

 

 

theusch wrote:
Yes, you can get spurious characters, usually/often framing errors. My "engine" just discards them when not expected, but in any case with the internal pullup enabled on the RX line you will get very few if any IME.

This makes the bus of cource more reliable, but how much effort have you put into analyzing where these errors come form?

 

One of the sources of errors on the bus I found was that during reset of the AVR the DE bit was floating, with spurious enables of the driver which sometimes maimed other packets on the bus. Therefore I added a 10k pulldown on the DE pin.

 

 

 

 

 

 

Doing magic with a USD 7 Logic Analyser: https://www.avrfreaks.net/comment/2421756#comment-2421756

Bunch of old projects with AVR's: http://www.hoevendesign.com

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

Enabling the internal pull-up worked like magic. Thank you!

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

This is described in several RS485 AN's.

https://www.avrfreaks.net/forum/r...

John Samperi

Ampertronics Pty. Ltd.

https://www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly