Hi all,
I have two hardware UARTs on a CM4 which are configured for RS485 mode using the PR into the Pi kernel 6.12.y that I submitted previously based on my previous forum post.
These are each connected to a Modbus RTU server running at 115200 baud (/dev/ttyAMA3) and 460800 baud (/dev/ttyAMA4) respectively.
We have a piece of .NET software running on the CM4 which continuously reads data from both of these servers, with no mutual exclusion between the two ports (i.e. it is assumed that both ports can be accessed simultaneously).
However, when reading large blocks of data on ttyAMA4 (> 10 Modbus registers per read, which could be due to a FIFO size, Modbus allows up to 125 registers to be read in a block) whilst also polling small blocks of data on ttyAMA3, the block reads on ttyAMA4 timeout very frequently. Reducing the polling rate on ttyAMA3 increases the reliability of Modbus comms on ttyAMA4, so it seems like a timing/collision issue.
Reading large blocks of data from either serial port works fine when each is used individually, the problems only occur when both ports are being used at the same time, which leads me to believe that there could be an issue with using multiple UARTs in RS485 mode at the same time, perhaps to some common dependency on the RTS lines used for driving the two transceivers, or a common interrupt?
Both of the busses are used as half-duplex, although strictly one uses a half-duplex transceiver and the other a full-duplex transceiver. I'm not sure if it would be of any benefit to try and put this UART into full-duplex mode by adding the "rs485-rx-during-tx" property to the device tree in a similar manner to my previous modifications, but I'm not actually sure what this property changes in the driver, perhaps enabling the receiver during transmission? Would this be worth trying or is it just clutching at straws?
All I could find on this problem online is an open issue (#5578) where someone seems to have a similar problem on the same Pi hardware with a similar application.
Does anyone have any ideas as to how this could be solved at a kernel configuration level? We don't really want to have to add mutual exclusion between the two ports in the software, but also if Modbus block reads are guaranteed to work reliably below a certain length due to buffering, we can split the reads up into chunks instead and just leave things as-is - we just need to know why the issue occurs and document the "fix" so that the software can be reliably maintained in future.
I've also noticed since adding the patches for the device tree overlays for the Pi UARTs that the overrides for RTS control (inversion, on delay, off delay) don't seem to be being applied properly - should the code below definitely work? It seems slightly different to how overrides are implemented on a dormant fragment compared to vc4-kms-dpi.dtsi for example. It would be useful to know because I would also like to add an override for "rs485-rx-during-tx" to allow full-duplex mode in case that helps.
/boot/firmware/config.txtuart3-overlay.dtsI'd be very grateful for some advice and assistance, thanks!
Many thanks,
Adam
I have two hardware UARTs on a CM4 which are configured for RS485 mode using the PR into the Pi kernel 6.12.y that I submitted previously based on my previous forum post.
These are each connected to a Modbus RTU server running at 115200 baud (/dev/ttyAMA3) and 460800 baud (/dev/ttyAMA4) respectively.
We have a piece of .NET software running on the CM4 which continuously reads data from both of these servers, with no mutual exclusion between the two ports (i.e. it is assumed that both ports can be accessed simultaneously).
However, when reading large blocks of data on ttyAMA4 (> 10 Modbus registers per read, which could be due to a FIFO size, Modbus allows up to 125 registers to be read in a block) whilst also polling small blocks of data on ttyAMA3, the block reads on ttyAMA4 timeout very frequently. Reducing the polling rate on ttyAMA3 increases the reliability of Modbus comms on ttyAMA4, so it seems like a timing/collision issue.
Reading large blocks of data from either serial port works fine when each is used individually, the problems only occur when both ports are being used at the same time, which leads me to believe that there could be an issue with using multiple UARTs in RS485 mode at the same time, perhaps to some common dependency on the RTS lines used for driving the two transceivers, or a common interrupt?
Both of the busses are used as half-duplex, although strictly one uses a half-duplex transceiver and the other a full-duplex transceiver. I'm not sure if it would be of any benefit to try and put this UART into full-duplex mode by adding the "rs485-rx-during-tx" property to the device tree in a similar manner to my previous modifications, but I'm not actually sure what this property changes in the driver, perhaps enabling the receiver during transmission? Would this be worth trying or is it just clutching at straws?
All I could find on this problem online is an open issue (#5578) where someone seems to have a similar problem on the same Pi hardware with a similar application.
Does anyone have any ideas as to how this could be solved at a kernel configuration level? We don't really want to have to add mutual exclusion between the two ports in the software, but also if Modbus block reads are guaranteed to work reliably below a certain length due to buffering, we can split the reads up into chunks instead and just leave things as-is - we just need to know why the issue occurs and document the "fix" so that the software can be reliably maintained in future.
I've also noticed since adding the patches for the device tree overlays for the Pi UARTs that the overrides for RTS control (inversion, on delay, off delay) don't seem to be being applied properly - should the code below definitely work? It seems slightly different to how overrides are implemented on a dormant fragment compared to vc4-kms-dpi.dtsi for example. It would be useful to know because I would also like to add an override for "rs485-rx-during-tx" to allow full-duplex mode in case that helps.
/boot/firmware/config.txt
Code:
dtoverlay=uart3,rs485,rs485_rts_on_delay=0,rs485_rts_off_delay=0Code:
rs485: fragment@2 {target = <&uart3>;__dormant__ {linux,rs485-enabled-at-boot-time;rs485-rts-delay = <0 0>;};};__overrides__ {ctsrts = <0>,"=1";rs485 = <0>,"=1=2";rs485_invert_rts = <&rs485>,"rs485-rts-active-low";rs485_rts_on_delay = <&rs485>, "rs485-rts-delay:0";rs485_rts_off_delay = <&rs485>, "rs485-rts-delay:4";};Many thanks,
Adam
Statistics: Posted by AdamWTracerco — Tue Dec 16, 2025 1:12 pm