About ORIN gpio value after rising edge

Autonomous Machines Jetson & Embedded Systems Jetson AGX Orin
1

We use ORIN module GPIO(pin:B8, GPIO3_PS.05) to capture gpio rising edge, it can capture the edge and go into the interrupt, but then get the gpio level, can’t get the high level.

the same driver works well on xavier module.

gpio driver irq handler source code like this:

static irqreturn_t gpio_irq_handler(int irq, void *data)
{
int after_rising_edge;

    info = data;

    after_rising_edge = gpiod_get_value(info->gpio_pin);

    return IRQ_HANDLED;

}

the 'after_rising_edge‘ is high on XAVIER, but still be low on ORIN.
what’s the difference about this GPIO on XAVIER and ORIN?

3

hello liu.jialu,

could you please check the pin number as following, # cat /sys/kernel/debug/gpio | grep PS.05
and, please try alter the pin by using GPIO number directly?

may I also know which Jetpack release you’re using?
can you reproduce the failure with the latest JP-5.1 release version?
thanks

4

Pin number confing is currect.
It seems like GPIO value read latency, we consecutive read the gpio for a while, until read the desired value, record the entry IRQ time and read desired value time, Calculation time difference; the print log shown that this process takes about 10ms.

static irqreturn_t pps_gpio_irq_handler(int irq, void *data)
{
        const struct pps_gpio_device_data *info;
        struct pps_event_time ts;
        int rising_edge;
        static long cnt = 0;
        int try_times = 10000;
        int read_times = 0;
        struct pps_event_time ts_after;

        /* Get the time stamp first */
        pps_get_ts(&ts);

        info = data;
		//add for debug
        do{
                rising_edge = gpiod_get_value(info->gpio_pin);
                try_times--;
                read_times++;
        }while(!rising_edge && try_times);

        pps_get_ts(&ts_after);
        
        if ((rising_edge && !info->assert_falling_edge) ||
                        (!rising_edge && info->assert_falling_edge))
        {
                pps_event(info->pps, &ts, PPS_CAPTUREASSERT, data);
                pps_cam_update_para();
        }
        else if (info->capture_clear &&
                        ((rising_edge && info->assert_falling_edge) ||
                        (!rising_edge && !info->assert_falling_edge)))
                pps_event(info->pps, &ts, PPS_CAPTURECLEAR, data);
        //add for debug
        cnt++;
        pr_info("%s line %d:rising_edge=%d, trigger_times=%ld, remain_try_times=%d, read_times=%d.\n", 
                                __func__, __LINE__, rising_edge, cnt, try_times, read_times);
                                
        if(ts_after.ts_real.tv_sec >- ts.ts_real.tv_sec)
        {               
                pr_info("Read gpio elapsed time:%lld ns.\n", 
                        (s64)(ts_after.ts_real.tv_sec - ts.ts_real.tv_sec) * 1000000000 + (ts_after.ts_real.tv_nsec - ts.ts_real.tv_nsec));
        }
        return IRQ_HANDLED;
}

9225f87476c299262e57783315a7f0e
9225f87476c299262e57783315a7f0e718×1056 21 KB

The irq is trigger on rising edge.

5

hello 525554536,

could you please examine axi_cbb, for example, # cat /sys/kernel/debug/bpmp/debug/clk/axi_cbb/rate

you may configure axi_cbb as higher clock rate to get better results,
for example,
# cd /sys/kernel/debug/bpmp/debug/clk/axi_cbb
# echo 408000000 > rate //or, whatever is the max rate
# echo 1 > mrq_rate_locked

please have a try, thanks

6

it is not worked. The problem remains.
We have update sdk package to JP-5.1, The problem still exists.
We tried to change the pps pin, but still can’t solve the problem. This problem still exists on the development board.
Is there a recommended GPIO?

7

hello liu.jialu,

could you please double check.
according to pinmux spreadsheets, it’s GPIO3_PAC.05 of pin-B8 on AGX Orin.

8

yes, it’s GPIO3_PAC.05on Orin, but it’s GPIO3_PS.05 on Xavier.
on Orin we use the GPIO3_PAC.05 (B8, GPIO11).
xavier works well, but orin can’t capture the GPIO edge in time.