This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM62L-PROCESSOR-SDK: Issue Configuring and Testing RS232 on wkup_uart0 (AM62L)

Part Number: AM62L-PROCESSOR-SDK


Tool/software:

Dear TI Support Team,

I am working with the TI AM62L3 processor and trying to configure wkup_uart0 as an RS232 interface. While other UARTs(rs485(ttys#) ,data uart (ttyS1/4)) are working correctly, RS232 on wkup_uart0 is not being detected. I have attempted enabling wkup_uart0 in two ways:

  1. Modifying arch/arm64/boot/dts/ti/k3-am62l-wakeup.dtsi – I set status = "okay", assigned the necessary clocks, and ensured proper interrupt configuration. However, after making these changes, the UART does not appear in /dev/ttyS*, and dmesg | grep -i tty does not list wkup_uart0. Additionally, I noticed corrupted boot logs with unknown symbols repeating, even though there is no kernel panic.

  2. Enabling wkup_uart0 in my board-specific device tree (k3-am62l-<board>.dts) – The same issue persists. The UART is still not detected, and the boot log corruption remains unchanged.

Other UART interfaces on the board are functioning correctly, and I have verified the clock, interrupt, and power-domain settings. Could you please provide guidance on the correct device tree configuration, necessary pinmux settings, and any additional testing methods to ensure wkup_uart0 is correctly initialized? Additionally, I would appreciate insights into potential causes for the corrupted boot output after enabling wkup_uart0. Any debugging suggestions or required changes would be helpfull.


&cbass_wakeup {

target-module@2b300050 {

wkup_uart0 {
bootph-all;
pinctrl-names = "default";
pinctrl-0 = <&wkup_uart0_pins_default>;
status = "okay";
};
};
};

wkup_uart0_pins_default: wkup_uart0-default-pins {
pinctrl-single,pins = <
AM62PX_MCU_IOPAD(0x0008, PIN_INPUT, 0) /* (W23) WKUP_UART0_CTSn */
AM62PX_MCU_IOPAD(0x000c, PIN_OUTPUT, 0) /* (W22) WKUP_UART0_RTSn */
AM62PX_MCU_IOPAD(0x0000, PIN_INPUT, 0) /* (Y22) WKUP_UART0_RXD */
AM62PX_MCU_IOPAD(0x0004, PIN_OUTPUT, 0) /* (AA23) WKUP_UART0_TXD */
>;
bootph-all;
};

Best regards,
Dheeraj

  • Hi Dheeraj,

    This is what is missing:

    target-module@2b300050 {

    wkup_uart0 {
    bootph-all;
    pinctrl-names = "default";
    pinctrl-0 = <&wkup_uart0_pins_default>;
    status = "okay";
    };

    The target-module@2b300050  is the parent node of wkup_uart0 and it is disabled in k3-am62l-wakeup.dtsi. So the parent node has to be enabled too.

    diff --git a/arch/arm64/boot/dts/ti/k3-am62l-wakeup.dtsi b/arch/arm64/boot/dts/ti/k3-am62l-wakeup.dtsi
    index e39fa3cd7ff2..72e7516208bd 100644
    --- a/arch/arm64/boot/dts/ti/k3-am62l-wakeup.dtsi
    +++ b/arch/arm64/boot/dts/ti/k3-am62l-wakeup.dtsi
    @@ -99,7 +99,7 @@ SYSC_OMAP2_SOFTRESET |
                    #address-cells = <1>;
                    #size-cells = <1>;
                    ranges = <0x0 0x00 0x2b300000 0x100000>;
    -               status = "disabled";
    +               status = "okay";
     
                    wkup_uart0: serial@0 {
                            compatible = "ti,am64-uart", "ti,am654-uart";

    However, after the wkup_uart0 is enabled in current SDK11.0, you would have the problem on main_uart0 as discussed in the thread linked below. Please use the solution provided in the thread.

    https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1492811/am62l-linux-a53-using-wkup_uart0-exception

  • Hi Bin,

    Thank you for sharing this workaround , this has resolved my issue. It would be helpfull for me if you care to share why that assigned clock rates was getting conflicted with the main_uart0.

    Regards,
    Dheeraj K

  • Hi Dheeraj,

    This is a sw bug. All the UART modules on AM62Lx uses the same PLL source for UART refclk, and the PLL by default is 96MHz. Now this wkup_uart0 devicetree changes the PLL to 48MHz which changes the baud rate of the console (main_uart0) by half, so messes up the receiving on the PC UART side.

  • Hi Bin,

    Thank You For the explanation. 

    Regards,
    Dheeraj k