Problems using BeagleBone Black's UART

[patrick...@gmail.com]

Hello!

I'm trying to use the BeagleBone Black to communicate to RS485 and CAN-Devices.
For testing I ordered the Waveshare RS485-CAN Cape. Later on the MAX13487 should be used for RS485 at UART2. CAN works fine using the BB-CAN1 overlay with uEnv.txt (UART1).

But first I tried to communicate from UART1 to UART2, to check if the UARTs are working. I added BB-UART1, BB-UART2 and BB-UART4 to uEnv.txt and connected UART1 RX to UART2 TX and UART1 TX to UART2 RX (Pins 22 and 24/ 26 and 21).

After Reboot, the UARTs are activated:

root@beaglebone:/# ls -l /dev/ttyO*
lrwxrwxrwx 1 root root 5 Feb  7 13:55 /dev/ttyO0 -> ttyS0
lrwxrwxrwx 1 root root 5 Feb  7 13:55 /dev/ttyO1 -> ttyS1
lrwxrwxrwx 1 root root 5 Feb  7 13:55 /dev/ttyO2 -> ttyS2
lrwxrwxrwx 1 root root 5 Feb  7 13:55 /dev/ttyO4 -> ttyS4

root@beaglebone:/# dmesg | grep tty
[    0.000000] Kernel command line: console=tty0 console=ttyO0,115200n8 capemgr.enable_partno=BB-UART1,BB-UART2,BB-UART4, BB-UART5 root=/dev/mmcblk0p1 rootfstype=ext4 rootwait coherent_pool=1M quiet cape_universal=enable
[    0.001090] console [tty0] enabled
[    0.001109] WARNING: Your 'console=ttyO0' has been replaced by 'ttyS0'
[    3.929029] 44e09000.serial: ttyS0 at MMIO 0x44e09000 (irq = 158, base_baud = 3000000) is a 8250
[    3.941849] console [ttyS0] enabled
[   22.142299] 48022000.serial: ttyS1 at MMIO 0x48022000 (irq = 189, base_baud = 3000000) is a 8250
[   22.154538] 48024000.serial: ttyS2 at MMIO 0x48024000 (irq = 190, base_baud = 3000000) is a 8250
[   22.165780] 481a8000.serial: ttyS4 at MMIO 0x481a8000 (irq = 191, base_baud = 3000000) is a 8250

Most tutorials using an older Debian version are using ttyOx to access the serial ports (old OMAP-driver?), but based on this output I have to use ttySx with the newer 8250 driver for my commands instead?

I tried to send/receive messages between the UARTs using minicom, screen and python scripts, but i can't see any messages at the receiving interface. Measuring the sending UARTs TX with an oscilloscope I also can't see any signals.

At the moment I am running Debian Image 2016-05-13 with Kernel 4.9.8-bone-rt-r4, I also tried everything with the original Kernel of this Image (4.4.9?) and a fresh Debian IoT Image 2016-12-09 and also with UART2+UART4.

Is there any missing configuration I have to do to get it working?

[patrick...@gmail.com]

[Micka]

I'm using the Omap driver for RS485, it works 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/1ce0353f-713c-4fda-afd8-55ac2ca506c7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Matthijs van Duin]

On Thursday, 9 February 2017 13:30:23 UTC+1, oetti133 wrote:

For testing I ordered the Waveshare RS485-CAN Cape.

Ehm, I noticed in its schematic that it ties the R-output of the CAN receiver directly to the UART_TX net. They did this presumably because can1_{rx,tx} use the same pins as uart1_{tx,rx} (note the difference in direction), although it's a mystery to me why they routed it through their uart jumper selection since only one jumper position is correct for can. This unnecessarily renders the simultaneous use of CAN and RS485 (via some uart other than uart1) on this cape impossible, but worse yet is that when configuring it for RS485 use there is a drive conflict between UARTn_TXD of the cpu and the R-output of the CAN receiver. Maybe it happens to work if the can receiver loses the fight over that net, but it's not going to be good for the health of either component.

 

Most tutorials using an older Debian version are using ttyOx to access the serial ports (old OMAP-driver?), but based on this output I have to use ttySx with the newer 8250 driver for my commands instead?

As you noticed it creates symlinks from ttyOx to ttySx when using the 8250-omap driver, so using ttyOx would still work fine and has the benefit of also working with the omap-serial driver (where ttySx would not).

I'm personally still not convinced about the merits of using the crusty 8250 driver instead of one dedicated to the omap uart. I haven't evaluated the quality of the omap-serial driver either though, but if I were to write a driver for this uart I would certainly use it in a way that avoids its 8250 legacy as much as possible rather than embracing it.

I tried to send/receive messages between the UARTs using minicom, screen and python scripts, but i can't see any messages at the receiving interface. Measuring the sending UARTs TX with an oscilloscope I also can't see any signals.

This is odd, we use them without problem on a 4.9 kernel using 8250-omap. Double-check your pinmux configuration, e.g. using my show-pins script, and try making sure the port is sanely configured, e.g.:

    stty -F /dev/ttyO1 sane raw clocal cread -crtscts 38400 cs8 -parenb -cstopb

    echo -e 'Hello world!\r\n' >/dev/ttyO1

Matthijs

[rituku...@gmail.com]

You can change /boot/uEnv.txt First of all enable UARTS:

cape_disable=bone_capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN
cape_enable=bone_capemgr.enable_partno=BB-UART1,BB-UART2,BB-UART4.BB-UART5

Then don't forget to configure pinmux with appropriate dtbo's:

###Overide capes with eeprom
uboot_overlay_addr0=/lib/firmware/BB-UART1-00A0.dtbo
uboot_overlay_addr1=/lib/firmware/BB-UART2-00A0.dtbo
uboot_overlay_addr2=/lib/firmware/BB-UART4-00A0.dtbo
uboot_overlay_addr3=/lib/firmware/BB-UART5-00A0.dtbo

[antoine.a...@gmail.com]

rituku thank you so much!!
I tried so many things but only the uboot_overlay lines made it work.

[jpfl...@gmail.com]

This also worked for me, I have spent days and days on this , thank you so much. 

There are so many config issues that this could be I can't tell you how many paths I went down, so many dtbo files that might change something or break, kernel options etc , again THANKS. 

[Matthijs van Duin]

For what? using the uarts? If you're using a recent image then you don't have to mess with overlays at all. In the default configuration, you can configure pin function at runtime using the "config-pin" utility, e.g. for uart4:

config-pin P9.11 uart   # switch P9.11 to uart 4 rxd

config-pin P9.13 uart   # switch P9.13 to uart 4 txd

The specific prerequisites for being able to do this are:

1. /boot/uEnv.txt contains 'enable_uboot_overlays=1' and 'enable_uboot_cape_universal=1' (both of these are typically present)

2. No cape overlay is loaded (as a result of cape autodetection or by setting one of the uboot_overlay-variables in /boot/uEnv.txt)

3. The bootloader is recent enough. This is automatic when running from eMMC, but if you're booting from SD card then the presence of an old bootloader on eMMC may cause problems. Reflashing eMMC fixes this problem, or you can just wipe eMMC using 'sudo blkdiscard /dev/mmcblk1'.

But indeed, using overlays instead is also still supported, set via the uboot_overlay_* variables in /boot/uEnv.txt. Do note that doing so implicitly disables "cape-universal", which means the config-pin utility won't work.

Matthijs