Unable to configure UART1 for SAI2_RXFS/SAI2_RXC pins for i.MX 8M Nano with Yocto Linux

[stmatscaps]

Because of a redesign of our custom board with a i.MX 8M Nano MIMX8MN5CVPIZAA CPU the RX and TX lines of UART1 were assigned to the SAI2_RXFS(Y13)/SAI2_RXC(AA15) pads. Previously UART1 worked without problems when assigned to the UART1_RX/UART1_TX pads.

These are the new device tree entries for UART1:

&uart1 {
fsl,dte-mode;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_uart1>;
status = "okay";
};

pinctrl_uart1: uart1grp {
fsl,pins = <
MX8MN_IOMUXC_SAI2_RXC_UART1_DTE_TX  0x140
MX8MN_IOMUXC_SAI2_RXFS_UART1_DTE_RX 0x140
>;
};

DTE mode is used, and with that we expect the following configuration:

Pad SAI2_RXC/AA15: input (DTE TX)
Pad SAI2_RXFS/Y13: output (DTE RX)

We verified that the electrical connections on the board are ok by configuring these pins as input and output GPIOs. Then we see output and input signals as expected. But when we configure these pins for UART1 operation it does not work.

It may be the case that we didn't get it right which pin is output and which pin is input in DTE mode because the documentation is somewhat confusing, but I think that we should see output activity on one of the two pins, even if we didn't understand the assignment of RX and TX correctly.

But no matter what when we send data to the UART1 tty from Linux there is no output signal on either pin.

How do we configure this correctly, and how can we troubleshoot this?

Thank you

Stephan

[stmatscaps · Accepted solution]

With the help of NXP support we tracked this down to the fact that there were conflicting pin mux settings applied from the bare-metal application that is running on the CM7 core of the board. After that was cleaned up, UART1 started to work as expected over the SAI2_RXFS/SAI2_RXC pins.

[Chavira]

Hi @stmatscaps,

Thank you for contacting NXP Support.

Your device tree configuration appears to be correct at first glance; however, I would like to review it in more detail on my side to be certain.

Could you please share your device tree file?

Additionally, please let me know:

• Which BSP version you are using
• Which board you are working with

Best regards,
Chavira

[stmatscaps]

Hi Chavira,

thank you for looking into this.

Our Yocto build is based on NXP's Yocto Scarthgap imx-6.6.52-2.2.2.xml manifest.

We are using a custom board. I'm sorry but I cannot share the schematics of this board.

I have attached two device tree source files:

• imx8mn-usc4.dts: Our device tree source file that includes the imx8mn.dtsi device tree file from the Linux kernel source.
• raw-device-tree.dts: This file was produced on the live system by reading the device tree from the /proc filesystem with the command "dtc -I fs -O dts /proc/device-tree/".

Best regards
Stephan

[meketok]

@stmatscaps 

1.  Have you measured both TX and RX?
2. Have you removed fsl, dte-mode; and then measured again?

One error is that the debug serial port uses DMA.
If you look at the 8MN EVK, the debug serial port does not use DMA. Using DMA will cause the debug information to not be real-time.
What you need to do is add DMA to the debug UART in the original BSP, and remove the DMA from the debug UART in the current design.

Original debug uart2 has no dma, in your design, you need to add them.

				serial@30890000 {
					pinctrl-names = "default";
					pinctrl-0 = <0x23>;
					clock-names = "ipg\0per";
					fsl,dte-mode;
					interrupts = <0x00 0x1b 0x04>;
					clocks = <0x02 0xaa 0x02 0xaa>;
					compatible = "fsl,imx8mn-uart\0fsl,imx6q-uart";
					status = "okay";
					reg = <0x30890000 0x10000>;
				};

Your current design debug uart1 has dmas, it is wrong, you need to remove them.

				serial@30860000 {
					pinctrl-names = "default";
					pinctrl-0 = <0x22>;
					clock-names = "ipg\0per";
					fsl,dte-mode;
					interrupts = <0x00 0x1a 0x04>;
					clocks = <0x02 0xa9 0x02 0xa9>;
					dma-names = "rx\0tx";
					compatible = "fsl,imx8mn-uart\0fsl,imx6q-uart";
					status = "okay";
					reg = <0x30860000 0x10000>;
					dmas = <0x1e 0x16 0x04 0x00 0x1e 0x17 0x04 0x00>;
				};

[stmatscaps]

1.  Have you measured both TX and RX?

Yes, I have measured both TX and RX.

2. Have you removed fsl, dte-mode; and then measured again?

Yes, I tried with and without "fsl, dte-mode;".

Thank you for your remark regarding the DMA configuration, but I don't think that this can be the cause of the problem. The UART was working find on the preceding revision of the board. The only thing that we want to change is the pin mux configuration to make the signals available on different pads of the chip.

Best regards
Stephan

[Chavira]

Hi @stmatscaps,

It appears that UART1 is correctly configured in the device tree, and the pin multiplexing for DTE mode looks consistent with the i.MX8M Nano documentation.

To continue troubleshooting, could you please sharet he output of dmesg,  and the output of ls /dev/ttymxc*?

This will help confirm that the UART driver is probed correctly and that the expected device node is present.

For reference:

UART1 (base address 0x30860000) should be enumerated in Linux as:
/dev/ttymxc0

In DTE mode, the signal directions are:
UART1_DTE_TX -> output → SAI2_RXC
UART1_DTE_RX -> input → SAI2_RXFS

When data is written to /dev/ttymxc0, activity should therefore be observed on SAI2_RXC.

The additional logs will allow us to verify that the correct UART instance is being used and that no driver level issues are preventing transmission.

[stmatscaps]

Hi @Chavira ,

I have attached the dmesg output, and this is the output of the ls-command:

root@imx8mn-usc4:~# ls -l /dev/ttymxc*
crw-rw----    1 root     dialout   207,  16 Feb 27  2024 /dev/ttymxc0
crw--w----    1 root     tty       207,  17 Feb  9 09:28 /dev/ttymxc1

 
Best regards
Stephan

[Chavira]

Hi @stmatscaps,

After reviewing your log file, UART1 is correctly detected by the system and appears to be working without any issues.

Please try the following commands to verify TX activity:

stty -F /dev/ttymxc0 115200 -crtscts -echo -onlcr
echo 'hello' > /dev/ttymxc0

After running these commands, you should observe activity on the SAI2_RXC pin.
If you do not see any signal, please run this command and share the output:

grep -E 'SAI2_RX(C|FS)' /sys/kernel/debug/pinctrl/*/pinmux-pins

If there is still no activity, please double‑check that you are probing the correct physical pins.

If you prefer not to share schematics publicly, you can open a private case in our support portal at no cost, and we can provide you with more detailed assistance.

[Adele]

@Chavira I need to remind you.

@stmatscaps  says 1. Previously UART1 worked without problems when assigned to the UART1_RX/UART1_TX pads.

This indicates that the UART module is working. The UART module itself is unrelated to whether iomux/pin is configured.

@stmatscaps  says 2. We verified that the electrical connections on the board are ok by configuring these pins as input and output GPIOs. Then we see output and input signals as expected. But when we configure these pins for UART1 operation it does not work.
This means there are no problems with the hardware connection.

[stmatscaps]

Hello @Chavira ,

thank you for further troubleshooting instructions.

I connected the oscilloscope to both relevant pins, and executed the commands that you provided (stty and echo). There was no output on either of the two pins.

This is the grep output that you requested:

root@imx8mn-usc4:~# grep -E 'SAI2_RX(C|FS)' /sys/kernel/debug/pinctrl/*/pinmux-pins
pin 108 (MX8MN_IOMUXC_SAI2_RXFS): 30860000.serial (GPIO UNCLAIMED) function pinctrl group uart1grp
pin 109 (MX8MN_IOMUXC_SAI2_RXC): 30860000.serial (GPIO UNCLAIMED) function pinctrl group uart1grp

Regarding the schematics I have to wait for a colleague. We will prepare relevant fragments from the schematics and I will upload them tomorrow after opening a private case in the support portal.

Best regards
Stephan

[Adele]

It's recommended to use `memtool dump iomux register runtime` to check if the pin's mux and settings are indeed as expected. You can also use `memtool` to directly write to the UART data registers for testing.

You can try sending and receiving data and check `/proc/interrupts` for any changes to the relevant interrupts, including UART interrupts and UART DMA interrupts.