Beaglebone black uart4 not receiving

[Brook Milligan <brook%nmsu.edu@localhost>]

I have a Beaglebone black with a comms cape and am trying to get RS-485 communication working.  The block diagram is as follows:

	userland program <—> kernel /dev/tty01 <—> BBB uart4 <—> comm cape <—> RS-485 bus <—> endpoint device

Bottom line: transmission from the board’s uart4 works, a device on the bus responds, the response is on the uart4 rx pin, but the kernel never reports bytes received to the userland application.  I’m hoping for help debugging this.  The following provides greater detail.

NetBSD: 10.99.10 (GENERIC) with sys/arch/arm/ti/ti_com.c v1.12, otherwise stock from October 2023.  The relevant device probe is:

	com1 at tisysc50: OMAP UART, 64-byte FIFO
	com1: interrupting on INTC irq 45

Beaglebone black: evbarm/earmv7hf kernel; see https://docs.beagleboard.org/latest/boards/beaglebone/black/ which includes schematics and pinouts for the connectors.  In brief, uart4 is the relevant device, which is /dev/tty01 in the kernel.  Its receive and transmit lines are on BBB P9 pin 11 and pin 13, which I can monitor with an oscilloscope and see the expected packets.  The device tree overlay for uart4 is in sys/external/gpl2/dts/dist/arch/arm/boot/dts/am33xx-l4.dtsi:

			uart4: serial@0 {
				compatible = "ti,am3352-uart", "ti,omap3-uart";
				clock-frequency = <48000000>;
				reg = <0x0 0x1000>;
				interrupts = <45>;
				status = "disabled";
			};

Comms cape: for the schematic see https://github.com/beagleboard/capes/blob/master/beaglebone/Comms/Comms_Cape_sch.pdf. As mentioned, though, signals are getting through the cape in both directions exactly as expected, so I do not expect the problem there.

RS-485 bus: the comms cape is connected to a device that speaks the Modbus protocol.  I can send and receive packets fine via a USB-RS485 adapter (/dev/ttyU0).  Using exactly the same program, I can also send Modbus packets to the device via the comm cape (uart4, /dev/tty01).  I know packets are being sent, because I can see them with an oscilloscope on both BBB P9 pin 13 and on the RS-485 bus; I can also see the device’s response on the oscilloscope on both BBB P9 pin 11 and on the RS-485 bus.  The oscilloscope decodes the bytes exactly as sent and as expected in response.  Thus, it is clear that the RS-485 bus is working and the transmit side of uart4 is working.

Communications program: the test program is c++ communicating via a Boost Asio serial port; a basic summary of that class is here 

	https://www.boost.org/doc/libs/1_84_0/doc/html/boost_asio/overview/serial_ports.html

which indicates a “just open, configure baud rate, etc., then read/write” mode of use.  The class API is here

	https://www.boost.org/doc/libs/1_84_0/doc/html/boost_asio/reference/basic_serial_port.html

As mentioned, the same compiled program works perfectly for send/receive with /dev/ttyU0 but only seems to send with /dev/tty01.  The RS-485 bus seems fine; only the pathway from the uart4 (/dev/tty01) receive input to the kernel to my communications program does not.

Questions:

- Is there something different about line disciplines for ttyU versus tty that would explain the difference?  If so, where would I find documentation?

- Is there something obvious about opening a tty device, e.g., for read/write, that I should be doing despite what is implied by the Asio documentation and what works with /dev/ttyU0?

- Are there diagnostics that would be useful for tracking the information through the kernel?  Is it possible, for example, that no interrupts are generated?  If so, how would I check?

- Are there any other things I should be considering here?

I’m not too comfortable with the tty driver and the relevant kernel layers, so I would greatly appreciate guidance.

Thanks for any help you can offer.

Cheers,
Brook