Jetpack 5.0.2: UART: CTS pin not working

I want to use uart’s cts pin as an pps signal source, and use ppscheck tool to monitor the signal, but it seem’s not working. here is my debug info

  1. connect the MCLK05 pin with UART1_CTS pin on Expansion 40-pin Header

  2. run ppscheck tool & output level 0/1 on MCLK05 pin

  3. here is the pinmux dts snapshot

hello kangqi236,

could you please also check that pin-7/ MCLK05 is actually measured low/high from the oscilloscope?

i checked the MCLK05 & UART1_CTS pin, there is an squre wave on it

hello kangqi236,

I don’t sure ppscheck could recognize that high/low state change issue by command-line,
however, could you please follow Topic 107409 for an example to configure a GPIO pin as PPS.

Hi, Jerry
the pps-gpio driver seems to have the same problem. here is my operation flow

  1. modify the kernel configure file : arch/arm64/configs/tegra_defconfig as below,
    the pps-gpio driver must be compiled to module. because the driver init sequence problem which can cause pps-gpio driver init failure.

  2. modify the device tree file: hardware/nvidia/platform/t23x/concord/kernel-dts/tegra234-p3701-0000-p3737-0000.dts as below,

  3. recompile the kernel, and relpace the orin’s current kernel image.

  4. reboot orin devkit.

  5. copy pps-gpio.ko to orin and insmod it.

  6. there now has 2 pps device node on /dev:
    /dev/pps0 : the kernel virtual pps node used to debug
    /dev/pps1: the gpio pps node

  7. connect the pin GPIO27 with pin MCLK05

  8. run trigger script to output low/high level on GPIO27

  9. run ppstest
    ppstest /dev/pps0 : result is ok
    ppstest /dev/pps1 : access timeout

  10. check the irq interrupt of pps pin, the interrupt counter increase 1 every 1 second.

the ppscheck tool will work normal if I test it with usb2serial device

hello kangqi236,

could you please also check kernel logs, if there any pps-gpio failures from kernel side?
for example, $ dmesg > klog.txt

Hi, cherry
kernel log:
klog.txt (86.9 KB)

hello kangqi236,

thanks for the logs. there’re fetch timeout failures.
we’ll arrange resources to look into it.
for example,

[  142.908760] pps pps0: PPS event at 1660874907.059153819
[  142.908779] pps pps0: capture assert seq #135
[  142.909215] pps pps0: PPS_FETCH
[  142.909222] pps pps0: timeout 3.000000000

Hi cherry,
thanks! BTW, please help to solve the problem of uart cts

hello kangqi236,

can you please check if the pin you are interested in being used by pps-gpio.
this can be done by checking with sysfs, i.e. $ cat /sys/kernel/debug/gpio

Hi, Jerry
the gpio is being used by pps-gpio

hello kangqi236,

sorry for late reply, let’s debug further.
could you please enable dynamic debug flag of pps driver.
for example,

# cd /sys/kernel/debug/dynamic_debug/
# echo file pps.c +p > control

furthermore, pps_cdev_pps_fetch() is a IOCTL call user passes the timeout values. if there was any errors, this IOCTL sequence/call would have failed.
we also need to check if there are issues in sequence of IOCTL, you may adding some debug prints as below to check whether API return any errors.
for example,

static long pps_cdev_ioctl(struct file *file,
                unsigned int cmd, unsigned long arg)
        case PPS_FETCH: {
                struct pps_fdata fdata;

                dev_dbg(pps->dev, "PPS_FETCH\n");

                err = copy_from_user(&fdata, uarg, sizeof(struct pps_fdata));
                if (err) {
                        pr_err("%s: add some debug prints...Line(%d)\n", __FUNC__, __LINE__);
                        return -EFAULT;

                err = pps_cdev_pps_fetch(pps, &fdata);
                if (err) {
                        pr_err("%s: add some debug prints...Line(%d)\n", __FUNC__, __LINE__);
                        return err;