Problems using BeagleBone Black's UART

GoogleGroups
1

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?

2

I’m using the Omap driver for RS485, it works well !

Micka,

3

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

4

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
5

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

6

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.

7