GPIO(CAM1_PWDN) Latency

Robotics & Edge Computing Jetson Systems Jetson Orin Nano
, , , , ,
1

It would be appreciated if you support us to solve the issue with using our camera.

〇 Goal
We would like to connect our camera module to the J21 of the Jetson Orin Nano Developer Kit and streaming images.

Module : Jetson Orin Nano [8GB Developer Kit version]
Carrier Board : Jetson Orin Nano Devkit | J21 connector
JetPack : 5.1.3
rootfs : microSD
We follow the steps in the following URL to flash the image.

〇 Questions
It would be appreciated if you review the questions and the following issue reports, and then answer the questions.

  1. Is there any case where hardware GPIO(CAM1_PWDN) requires 150ms latency to output the value set by gpio_set_value() in the V4L2 driver?
  2. How to reduce the latency from gpio_set_value() in the V4L2 driver to the hardware GPIO(CAM1_PWDN) output (e.g.less than 1ms)?
  3. How long should we add the time to adjust the 150ms latency to output the value set by gpio_set_value() in the V4L2 driver?
    Because we are not sure if adding 150 ms is enough in other Jetson Orin Nano devkit boards or other modules.
  4. Are there steps to narrow down the issue from the GPIO(CAM1_PWDN) transition latency to others?

〇Issue Analysis
We also have the Auvidea JNX42 carrier board that succeeded in streaming images with the identical camera board, Orin Nano module, and V4L2 driver source code.

Module : Jetson Orin Nano [8GB Developer Kit version]
Carrier Board : JNX42 | J5 Connector
JetPack : 5.1.3
rootfs : NVMe SSD
We follow the following URL to flash the image.

The GPIO(CAM1_PWDN) latency of Jetson Orin Nano Devkit(J21 connector) is longer than that of the JNX42 carrier board(J5 connector). The GPIO(CAM1_PWDN) latency of Jetson Orin Nano Devkit(J21 connector) requires around 150 ms.

The V4L2 driver uses the GPIO(CAM1_PWDN) as the camera reset in the following power-on sequence. The steps of the power sequence are the following.
Step 1: Set High to the GPIO pin(CAM1_PWDN) to release the reset of the camera module.
Step 2: Wait 300 ms for the camera initialization.
Step 3: Read the register to see if the initialization succeeded.

We probed the GPIO pin(CAM1_PWDN), CAM_I2C_SDA, and CAM_I2C_SCL to confirm the waiting time in step 2.
The waiting time was around 150 ms if we use the Jetson Orin Nano Devkit.
We assume that usleep_range() works fine because the log says there is a 300 ms waiting time.
We also saw the waveforms where the waiting time changes according to the usleep_range() setting with the Jetson Orin Nano Devkit.
For example, the waiting time extended to 1000 sec with the waveform if we added 700 ms to the waiting time.

You can check the V4L2 driver source code and device tree files for the investigation.

The device tree files were generated from the boot/extlinux/extlinux.conf by reverse compiling.
Device Tree and V4L2 Driver Source Code.zip (108.2 KB)

kernel_tegra234-p3767-0003-p3509-a02-user-custom.dts : Auvidea JNX42 Carrier Board
kernel_tegra234-p3767-0003-p3768-0000-a0-user-custom.dts : Jetson Orin Nano Devkit
myCamera.c : V4L2 driver source code (Excerpt)

It would be appreciated if you kindly review our issue and give us feedback.

Best regards,

5

hello user86772,

I don’t see such GPIO set latency on Orin NX Developer kit.
could you please try using gpio_time = ktime_to_ms(ktime_get()); to obtain the timestamps for checking.
for example,

    s64 gpio_start = 0, gpio_end = 0;
    gpio_start = ktime_to_ms(ktime_get());
    //gpio_set()
    gpio_end = ktime_to_ms(ktime_get());
    pr_err("%s: GPIO set latency to is.. %lld ms\n", __func__, (gpio_end-gpio_start));
6

Hello JerryChang

Thanks for your reply and advice.

I don’t see such GPIO set latency on Orin NX Developer kit.

We are using Orin Nano developer kit, not Orin NX. I might type in my previous message.

could you please try using gpio_time = ktime_to_ms(ktime_get()); to obtain the timestamps for checking.

Yes. We used gpio_time = ktime_to_us(ktime_get()); instead of ktime_to_ms(ktime_get()) because the time on the log was very short (e.g 0 ms).

Please find the attached log files, full and excerpt.
Orin_Nano_Devkit.zip (42.8 KB)

The GPIO transition time is very short from the log. We also added the code to see that there is a 300ms waiting time on the log, “usleep_range latency to is..”.

We verified the time with the oscilloscope. There is no 300 ms time in the waveform. Could you also review the attached waveform?
We think the GPIO transition time on the log and/or the waiting time would be different from the actual time.

The waveform has the CAM1_PWDN(ch3: purple) high to the first I2C(ch1: yellow and ch2: blue) communication. We use “usleep_range(300000, 300100);” to make the wait time between CAM1_PWDN high to the first I2C.

PS.
The I2C and reset input to the switch IC and level shifter IC to change the voltages from 3.3V to 1.8V. The level shifter and switch IC propagation delay is “ns” order.

Best regards,

9

hello user86772,

may I know which camera module you’re using? did you also check with the camera vendor for the camera power sequence?
besides.. could you please also check with Orin Nano reference camera (i.e. IMX219 or IMx477) for comparison.

10

Hello JerryChang

may I know which camera module you’re using?

Sorry, but I do not want to disclose the camera module name so far.
The identical camera module works with the Jetson Orin Nano on the JNX42 carrier board and other SoC platforms.

did you also check with the camera vendor for the camera power sequence?

Yes, we did.

could you please also check with Orin Nano reference camera (i.e. IMX219 or IMx477) for comparison.

You might concern about the camera design or manufacturing failure; however, the camera works fine if we use the camera with the Jetson Orin Nano module(the identical module) on another carrier board and other SoCs’ EVKs.
Thus, we think the camera is OK.

I guess both IMX219 and IMX477 work because these are “reference camera”. I am not sure the test with IMX219 or IMX477 help the debug. Because the issue changes when change the carrier board. It would be appreciated if you explain.

The issue is that Jetson Orin Nano Devkit board does not apply the initial sequence according to the V4L2 driver. The time from CAM1_PWDN to first I2C is short. Another carrier board can apply the sequence with same V4L2 driver, and we can get the images from the camera.

Did you review the log files and waveform in my previous post?

11

Hello JerryChang

As you’re saying, CAM1_PWDN seems to be transitioning without a long delay.

We shorted CAM1_PWDN pin with CAM1_MCLK which GPIO input mode, and then read the values. We confirmed that the CAM1_MCLK reads the high of CAM1_MCKL without any delay.

We will confirm the other portion, including our camera, more carefully.

Thanks for your support.

Best regards,

13

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.