I’ve been stuck on this problem for a while now and tried dozens of fixes, so I apologize in advance if this all seems a bit scatterbrained.
I am bringing up a custom Toradex image using Yocto for the IMX8MM Verdin SOM. We are using verdin-uart1 (serial@30890000
) and verdin-uart2 (serial@30880000
) to interface with two separate RS-485 devices running at 921600 baud.
With the current configuration, we are able to send all the data we want and the target devices correctly receive it all. When receiving data back from those devices (depending on how I’ve screwed up the image on any given day), we either drop random chunks of some of the received data (typically 25 or 26 bytes out of the middle of a packet) or are unable to receive any data.
In today’s debugging, the UARTs were configured like this in the relevant .dtsi file:
uart2: serial@30890000 {
compatible = "fsl,imx8mm-uart", "fsl,imx6q-uart";
reg = <0x30890000 0x10000>;
interrupts = <GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clk IMX8MM_CLK_UART2_ROOT>,
<&clk IMX8MM_CLK_UART2_ROOT>;
clock-names = "ipg", "per";
status = "okay";
linux,rs485-enabled-at-boot-time;
};
uart3: serial@30880000 {
compatible = "fsl,imx8mm-uart", "fsl,imx6q-uart";
reg = <0x30880000 0x10000>;
interrupts = <GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clk IMX8MM_CLK_UART3_ROOT>,
<&clk IMX8MM_CLK_UART3_ROOT>;
clock-names = "ipg", "per";
status = "okay";
linux,rs485-enabled-at-boot-time;
};
With these settings, we can reliably receive single bytes in a simple loopback test by running echo -n -e 'a' > verdin-uart1
on one port and cat verdin-uart2
on the other. I have also configured both UARTs to a “raw” mode with stty -F /dev/verdin-uart1 -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -icanon -opost -isig -iuclc -ixany -imaxbel -xcase min 1 time 0
(please let me know if there’s a simpler command).
However, when sending two bytes, the second byte is never received by the receiving UART. I can see on an oscilloscope that the UART line of the SOM is indeed receiving the bytes, but somehow the Linux driver/buffer/something is not handling them. When sending more than 2 bytes, any possible combination of letters and characters come through in a jumbled mess (like more than half of the bits are not being received).
This is similar but not exactly consistent with our issue of dropping larger chunks of data, but I believe the device tree configuration is the same in both cases.
Today I also attempted to add a DMA buffer to these UARTs, by adding the line dma-names = "rx", "tx";
into the device declarations. Linux is not able to receive any data in the loopback test with this set, so I’m assuming that either it’s wrong to add there or my DMAs are set up incorrectly.
I would appreciate any advice or recommendations for other tests. Thank you!