RS485 problem with DE/!RE

[florian.f...@googlemail.com]

Hey all,

I'm using the Debian Jessie image with kernel version 4.4.6-ti-r15 on my BeagleBone Black.

To monitor our vacuum system in the lab, we need a RS485 interface, so I simply connected an ADM2682 RS422/485 line driver
to UART4 of the BeagleBone using this Device Tree Overlay
BB-UART4-RS485-00A0.dts (commit 16f76f7 on master branch)

P9.27 is connected to the DE and !RE inputs of the chip.

Using this for sending works just fine, but I have problems receiving messages over the bus.

For testing I wrote a small C-program which should read on the bus until it gets two times a timeout.
The reading is done via select-call with a 5 second timeout.
The device on the other end of the bus is contentiously sending data over the bus.
After receiving 49 bytes at most, the DE/!RE line goes up and my BeagleBone stops receiving any data...

I've uploaded a screenshot of the scope showing the three signals from the UART interface
Scope

Does anyone has a clue what could go wrong?

Any help appreciated!
Regards
Florian

[florian.f...@googlemail.com]

Hey all,

I did some further tests.
Actually none of the screens from my scope looks like I would expect it...

Picture 1 shows the result, if I try to read something on the bus with a 14s timeout (nothing was sended on the bus...)
Pic1
Picture 2 shows the same, but this time there were messages send over the bus. After 49 bytes, the beagle bone toggles the DE/!RE gpio to high for unknown reasons (the test program is still reading from the UART interface)
Pic2
Picture 3 shows the test, where the BeagleBone is sending
Pic3
and finally picture 4 shows a test, where the BeagleBone should read (timeout 3s) on the bus, then send something and again reading (with 3s timeout)...
Pic4
As you see, DE/!RS stays high after sending, although it should be low...

In addition I would expect this line to be low when the port is not used, but it's high..

I checked if there is any other process (or driver) accessing GPIO3_19 but I could not find any...

Any help is very much appreciated!
Florian

[Harvey White]

On Mon, 25 Apr 2016 04:31:43 -0700 (PDT), you wrote:

>Hey all,

I can't tell you Beaglebone specifics, but to stop after a certain
number of characters and set DE/!RE high (I'm guessing this is a full
indication?), sounds like you've hit the limits on a buffer of some 50
bytes, so it may be that you're running up against this limit.

Normally, when you read data from a hardware UART within a chip, the
internal FIFO in the hardware is cleared of that byte, data flags are
reset.

It sounds as if something's not being done.

If there is a software FIFO involved, and you're reading the data
directly from the chip (not sure how), then the FIFO is loaded, but
never read. When it's full, the serial interface should tell the
transmitter to stop sending.

These, of course, are just guesses.

Harvey

>
>I did some further tests.
>Actually none of the screens from my scope looks like I would expect it...
>
>Picture 1 shows the result, if I try to read something on the bus with a
>14s timeout (nothing was sended on the bus...)

>Pic1 <http://www.ep1.rub.de/~florian/rs485_test_reading_timeout.png>

>Picture 2 shows the same, but this time there were messages send over the
>bus. After 49 bytes, the beagle bone toggles the DE/!RE gpio to high for
>unknown reasons (the test program is still reading from the UART interface)

>Pic2 <http://www.ep1.rub.de/~florian/rs485_test_reading.png>

>Picture 3 shows the test, where the BeagleBone is sending

>Pic3 <http://www.ep1.rub.de/~florian/rs485_test_sending.png>

>and finally picture 4 shows a test, where the BeagleBone should read
>(timeout 3s) on the bus, then send something and again reading (with 3s
>timeout)...

>Pic4 <http://www.ep1.rub.de/~florian/rs485_test_3sRead-send-3sRead.png>

>As you see, DE/!RS stays high after sending, although it should be low...
>
>In addition I would expect this line to be low when the port is not used,
>but it's high..
>
>I checked if there is any other process (or driver) accessing GPIO3_19 but
>I could not find any...
>
>Any help is very much appreciated!
>Florian
>
>
>
>Am Freitag, 22. April 2016 15:22:48 UTC+2 schrieb
>florian.f...@googlemail.com:
>>
>> Hey all,
>>
>> I'm using the Debian Jessie image with kernel version 4.4.6-ti-r15 on my
>> BeagleBone Black.
>>
>> To monitor our vacuum system in the lab, we need a RS485 interface, so I
>> simply connected an ADM2682 RS422/485 line driver
>> to UART4 of the BeagleBone using this Device Tree Overlay
>> BB-UART4-RS485-00A0.dts

>> <https://github.com/RobertCNelson/bb.org-overlays/blob/master/src/arm/BB-UART4-RS485-00A0.dts> (commit

>> 16f76f7 on master branch)
>>
>> P9.27 is connected to the DE and !RE inputs of the chip.
>>
>> Using this for sending works just fine, but I have problems receiving
>> messages over the bus.
>>
>> For testing I wrote a small C-program which should read on the bus until
>> it gets two times a timeout.
>> The reading is done via select-call with a 5 second timeout.
>> The device on the other end of the bus is contentiously sending data over
>> the bus.
>> After receiving 49 bytes at most, the DE/!RE line goes up and my
>> BeagleBone stops receiving any data...
>>
>> I've uploaded a screenshot of the scope showing the three signals from the
>> UART interface

>> Scope <http://www.ep1.rub.de/~florian/rs485.png>

[Taceant Omnes]

On 25 April 2016 at 12:31, florian.feldbauer85 via BeagleBoard

<beagl...@googlegroups.com> wrote:
> Hey all,
>
> I did some further tests.
> Actually none of the screens from my scope looks like I would expect it...
>
> Picture 1 shows the result, if I try to read something on the bus with a 14s
> timeout (nothing was sended on the bus...)
> Pic1
> Picture 2 shows the same, but this time there were messages send over the
> bus. After 49 bytes, the beagle bone toggles the DE/!RE gpio to high for
> unknown reasons (the test program is still reading from the UART interface)
> Pic2
> Picture 3 shows the test, where the BeagleBone is sending
> Pic3
> and finally picture 4 shows a test, where the BeagleBone should read
> (timeout 3s) on the bus, then send something and again reading (with 3s
> timeout)...
> Pic4
> As you see, DE/!RS stays high after sending, although it should be low...
>
> In addition I would expect this line to be low when the port is not used,
> but it's high..
>
> I checked if there is any other process (or driver) accessing GPIO3_19 but I
> could not find any...
>
> Any help is very much appreciated!

Any chance you could post a picture of a simple drawing of how you
connected the 485 driver to the BB (like which pin to which pin and
any extra components)? Also could you post your small C test program?

[Micka]

HI,

I don't have time to read your mail, but If you want to use rs485 on kernel 4.1/4.4 you have to use the omap driver and not 8250( which is the default ).

Look at this link : 

http://lxr.free-electrons.com/source/drivers/tty/serial/omap-serial.c?v=4.4#L1558

You can see that the property "rs485-rts-active-high" is used only on the driver omap and not 8250 . 


with that the rs485 work well ^^

micka,

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/4811b6af-b1dc-4909-a972-62f2c5f35fd2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[florian.f...@googlemail.com]

Hey,

@Alex: I recommend, you read my mail ;-)
I did not look into the kernel source nor am I sure which driver is used in my Setup,
but the problem is not the "rs485-rts-active-high" flag
When sending, the RTS (or DE/!RE) signal behaves as expected. Only during receiving (and IMHO when idle)
the flag does not.

here is the schematic of my current test setup.

 

Concerning my test program :
rs485_test.c
(it's a ugly quick'n'dirty implementation...)

The RS485 line driver is connected to a RS485-RS232 Converter which is connected to a linux PC.
On this linux PC, the same program is used for the tests.

Cheers,
Florian

[Peter Hurley]

On 04/26/2016 12:07 AM, florian.feldbauer85 via BeagleBoard wrote:
> @Alex: I recommend, you read my mail ;-)

I suggest you re-read his email again where he tells you that
RS485 is unsupported by your kernel configuration.

[Taceant Omnes]

On 26 April 2016 at 08:07, florian.feldbauer85 via BeagleBoard

<beagl...@googlegroups.com> wrote:

>> > I did some further tests.
>> > Actually none of the screens from my scope looks like I would expect it...
>> >
>> > Picture 1 shows the result, if I try to read something on the bus with a 14s
>> > timeout (nothing was sended on the bus...)
>> > Pic1
>> > Picture 2 shows the same, but this time there were messages send over the
>> > bus. After 49 bytes, the beagle bone toggles the DE/!RE gpio to high for
>> > unknown reasons (the test program is still reading from the UART interface)
>> > Pic2
>> > Picture 3 shows the test, where the BeagleBone is sending
>> > Pic3

Your scope picture #3 does appear to show data being sent, however you
seem to say that your picture #2 portrays a test in which you received
49 bytes, however I don't see any sign of data being received in that
picture. Maybe I am missing something.

I am not an expert in these things, but my current understanding is
that what the 485 driver provides extra to what the UART driver does
is the automatic switch of the driver enable pin. One test I would
suggest, a test I have done myself, is to send and receive data with
485 using the UART driver. In this case the DE/RE needs to be set
manually. I do it using echo to /sys/class/gpio. Once that is working
well you could start test usinging the 485 driver. You should be able
to use your existing rs485_test.c program for that.

>> @Alex: I recommend, you read my mail ;-)
>> I did not look into the kernel source nor am I sure which driver is used in my Setup,
>> but the problem is not the "rs485-rts-active-high" flag

As Micka and Alex said the 4.1 and 4.4 driver do not have 485 support
enabled. Per an email by Robert you need to enable the OMAP serial
kernel configuration option and rebuild the kernel.

[Taceant Omnes]

On 28 April 2016 at 12:36, Taceant Omnes <tac...@gmail.com> wrote:

> As Micka and Alex said the 4.1 and 4.4 driver do not have 485 support
> enabled. Per an email by Robert you need to enable the OMAP serial
> kernel configuration option and rebuild the kernel.

Per email by Robert with respect to kernel options:
"
disable: CONFIG_SERIAL_8250_OMAP

enable: CONFIG_SERIAL_OMAP
"

[Florian Feldbauer]

On 04/28/2016 01:36 PM, Taceant Omnes wrote:
> On 26 April 2016 at 08:07, florian.feldbauer85 via BeagleBoard
> <beagl...@googlegroups.com> wrote:
>
>>>> I did some further tests.
>>>> Actually none of the screens from my scope looks like I would expect it...
>>>>
>>>> Picture 1 shows the result, if I try to read something on the bus with a 14s
>>>> timeout (nothing was sended on the bus...)
>>>> Pic1
>>>> Picture 2 shows the same, but this time there were messages send over the
>>>> bus. After 49 bytes, the beagle bone toggles the DE/!RE gpio to high for
>>>> unknown reasons (the test program is still reading from the UART interface)
>>>> Pic2
>>>> Picture 3 shows the test, where the BeagleBone is sending
>>>> Pic3
> Your scope picture #3 does appear to show data being sent, however you
> seem to say that your picture #2 portrays a test in which you received
> 49 bytes, however I don't see any sign of data being received in that
> picture. Maybe I am missing something.

in all 4 picture from my 2nd post, channel 4 (green) shows one of
the two data lines of the bus.
Looking at #2 one can see, that this signal is starting toggling shortly
before
the DE/RE signal goes high. That's the 49 bytes I receive. After that
the data line
is still toggling araound but no longer between 0 and 1 but something in
between,
because now, there are two devices sending on the bus. One is still the
PC which
sends random data, the other one is the BeagleBone sending a constant 0...
(TX and DE/RE are constant high)

>
> I am not an expert in these things, but my current understanding is
> that what the 485 driver provides extra to what the UART driver does
> is the automatic switch of the driver enable pin. One test I would
> suggest, a test I have done myself, is to send and receive data with
> 485 using the UART driver. In this case the DE/RE needs to be set
> manually. I do it using echo to /sys/class/gpio. Once that is working
> well you could start test usinging the 485 driver. You should be able
> to use your existing rs485_test.c program for that.
>
>>> @Alex: I recommend, you read my mail ;-)
>>> I did not look into the kernel source nor am I sure which driver is used in my Setup,
>>> but the problem is not the "rs485-rts-active-high" flag
> As Micka and Alex said the 4.1 and 4.4 driver do not have 485 support
> enabled. Per an email by Robert you need to enable the OMAP serial
> kernel configuration option and rebuild the kernel.

I'm still a bit puzzled how "rs485 is not supported" looks like...
For me, being able to send and receiving data is quiet the
contrary of "not supported".
Where can I find the sources of the kernel used in the
debian-jessie-console 8.4 image
from April 07 in order to rebuild it? (I prefer changing as less as
possible, thus I'd like
to use the exact same kernel source tree as it is now)

Best regards,
Florian
>

[Florian Feldbauer]

Just found the link to Roberts script-repo at github..
I will rebuild the kernel with the OMAP driver and test the RS485
interface again...

Florian
>
> Best regards,
> Florian
>>
>

[florian.f...@googlemail.com]

Hey,

I had a look at the kernel source at github. From the code
I would say the 8250 driver supports RS485. Only the "rs485-rts-active-high" flag from the device tree overlay
seems not to be supported. But the same setting can be done via the struct serial_rs485 from user space.

Also RS485 seems to be working to a limited point.
Again: The only problem is receiving messages, which seems for what ever reason to be limited to 49 bytes.
If my kernel is not supporting RS485 I would expect that either sending or receiving is not working at all.
But from all the Pictures I linked in my previous mails, you can see, that the 8250 driver is switching the
RTS signal with the correct polarity.

Can someone point to to the kernel source for the kernel I am using (4.4.6-ti-r15)?
At least looking at the releases/tags in the repo at github this version is not listed...
I'd like to have a look at the exact same source which is currently running on my setup,
to see if there is some bug or missing support in the kernel...

Cheers
Florian

[Robert Nelson]

On Thu, Apr 28, 2016 at 1:56 AM, florian.feldbauer85 via BeagleBoard <beagl...@googlegroups.com> wrote:

Hey,

I had a look at the kernel source at github. From the code
I would say the 8250 driver supports RS485. Only the "rs485-rts-active-high" flag from the device tree overlay
seems not to be supported. But the same setting can be done via the struct serial_rs485 from user space.

Also RS485 seems to be working to a limited point.
Again: The only problem is receiving messages, which seems for what ever reason to be limited to 49 bytes.
If my kernel is not supporting RS485 I would expect that either sending or receiving is not working at all.
But from all the Pictures I linked in my previous mails, you can see, that the 8250 driver is switching the
RTS signal with the correct polarity.

Can someone point to to the kernel source for the kernel I am using (4.4.6-ti-r15)?

Grab https://github.com/RobertCNelson/yakbuild  follow the readme..

For 4.4.6-ti-r15, select:

toolchain="gcc_linaro_gnueabihf_5"

kernel_tag="4.4.6-ti-r15"

source:

https://github.com/RobertCNelson/linux-stable-rcn-ee/tree/4.4.6-ti-r15

Regards,

--

Robert Nelson
https://rcn-ee.com/

[Florian Feldbauer]

Hey,

I rebuild the kernel changing the configuration as mentiond by Taceant,
copied the new kernel onto my SD card and put it back into my BBB.
The board boots, everything seems fine, so I install
the device tree overlays (bb.org-overlay repo) and reboot the board,
as suggested by the install script.
After that, the BeagleBone Black no longer boots.

Here is what I changed in the kernel config:

~ > diff yakbuild/KERNEL/.config yakbuild/KERNEL/.config.old
2551c2551,2552
< # CONFIG_SERIAL_8250_OMAP is not set
---
> CONFIG_SERIAL_8250_OMAP=y
> CONFIG_SERIAL_8250_OMAP_TTYO_FIXUP=y
2565,2566c2566
< CONFIG_SERIAL_OMAP=y
< # CONFIG_SERIAL_OMAP_CONSOLE is not set
---
> # CONFIG_SERIAL_OMAP is not set

Did I miss anything?
I tried this with Kernel version 4.4.6-ti-r15 as well
as 4.4.8-ti-r22. Same result with both kernels

Cheers,
Florian

[Florian Feldbauer]

On 04/29/2016 09:43 AM, Florian Feldbauer wrote:

On 04/28/2016 03:47 PM, Robert Nelson wrote:

Hey,

I rebuild the kernel changing the configuration as mentiond by Taceant,
copied the new kernel onto my SD card and put it back into my BBB.
The board boots, everything seems fine, so I install
the device tree overlays (bb.org-overlay repo) and reboot the board,
as suggested by the install script.
After that, the BeagleBone Black no longer boots.

Here is what I changed in the kernel config:

~ > diff yakbuild/KERNEL/.config yakbuild/KERNEL/.config.old
2551c2551,2552
< # CONFIG_SERIAL_8250_OMAP is not set
---
> CONFIG_SERIAL_8250_OMAP=y
> CONFIG_SERIAL_8250_OMAP_TTYO_FIXUP=y
2565,2566c2566
< CONFIG_SERIAL_OMAP=y
< # CONFIG_SERIAL_OMAP_CONSOLE is not set
---
> # CONFIG_SERIAL_OMAP is not set

Did I miss anything? I tried this with Kernel version 4.4.6-ti-r15 as well
as 4.4.8

I mounted the SD card and deleted the initrd.img-`uname -r` file. After that, the BeagleBone was booting again.
But: Loading the BB-UART4-RS485 device tree overlay manually, I can now receive data over the RS485 bus,
but I can no longer send data.
So it seems the OMAP driver is not working either. Actually now it is even worse than before using the 8250 driver.

  Florian

[Taceant Omnes]

On 29 April 2016 at 10:18, 'Florian Feldbauer' via BeagleBoard

<beagl...@googlegroups.com> wrote:

> Did I miss anything? I tried this with Kernel version 4.4.6-ti-r15 as well
> as 4.4.8
>
> I mounted the SD card and deleted the initrd.img-`uname -r` file. After
> that, the BeagleBone was booting again.
> But: Loading the BB-UART4-RS485 device tree overlay manually, I can now
> receive data over the RS485 bus,
> but I can no longer send data.
> So it seems the OMAP driver is not working either. Actually now it is even
> worse than before using the 8250 driver.

Sorry that it did not work.

What about trying a 4.1.x kernel as some people seem to have had
success with it? However I would suggest installing a Debian image
that comes with a 4.1 kernel rather than using a 4.1 kernel on your
current image. Last year I had a problem with some sort of systemd
incompatibility with a kernel when I upgraded a kernel whereby the BBB
would not boot.

[Florian Feldbauer]

I prepared a second SD card with an older Debian Jessie image,
which is using a 4.1 kernel.
I rebuild the kernel, making the same modifications as for the 4.4 kernel.

With the 4.1 Kernel, loading the RS485 overlay via uEnv.txt works, but
still the DE/!RE line does nothing.

BTW: some mails ago I included a schematic of my setup. I just realized
that there is a mistake in it. DE/!RE is of course connected to P9-27
and not
to P9-25 as drawn in the picture.
I actually checked it now several times, that I have it correctly wired :D

Florian

[Florian Feldbauer]

On 04/29/2016 12:06 PM, Taceant Omnes wrote:

Hey all,

I have to apologize for my last two mails, because I made a stupid
mistake...
If you look at the source of my test program (6th message in this thread)
I only set the SER_RS485_ENABLED flag in the struct serial_rs485.
This didn't work, so I uncommented the next two lines which were
rs485conf.flags |= SER_RS485_RTS_ON_SEND;
rs485conf.flags &= ~SER_RS485_RTS_ON_SEND;

Of course this tells the RTS signal to be always 0 which does not work...
Fixing this bug, RS485 is now working with both kernels, 4.1 and 4.4,
using the OMAP driver...

Many thanks for your help and support!

Cheers,
Florian

[Taceant Omnes]

On 29 April 2016 at 13:39, 'Florian Feldbauer' via BeagleBoard

Great news that it is all working!

I wonder, have you seen in the scope how many milliseconds does it
take for DE/RE to switch from high to low after the BB finishes
writing a block of data to the bus?

Would you please post the .dts files you used with the 4.1 and 4.4
kernels to enable RS485?

[Florian Feldbauer]

Using the config 9600 8N1 for testing, I get a delay of about 29.2 us
between the falling edge of the DE/RE signal and the end of the stop bit
of the UART.

For my tests I used this dts file:
https://github.com/RobertCNelson/bb.org-overlays/blob/master/src/arm/BB-UART4-RS485-00A0.dts

[Taceant Omnes]

On 29 April 2016 at 14:48, 'Florian Feldbauer' via BeagleBoard

Thanks.