Frame Capture Error

Hi

I am getting an error as shown in the link below. I followed the solution but the error still occurs.

We do csi_output_enable in DES when we do streaming

The trace log doesn’t show any specific errors.

I think the expected problem is the SOF error for the first frame that comes out when csi_output_enable is enabled.

Is that right?

The photo below is a photo that saved two frames. As you can see, the green part is visible in the first frame.

image-20241002-061632

Is it possible bypass the GMSL to clarify the problem?

What does it mean to bypass gmsl?

Connect the sensor to AGX Orin directly.
Or try the test pattern from the GMSL chip.

Thanks

Structurally, the sensor cannot be directly attached.

However, if csi output the sensor driver probe without using the enable and disable registers, the symptom will disappear.

The setting value refers to the smax9295.c max9296.c setting in the BSP.

Is this symptom an original symptom?

Or do you have any doubts?

Hi @rlatae123

Could you please provide the full log of the trace VI?

Thanks,

Oscar Fallas
Embedded SW Engineer at RidgeRun
Contact us: support@ridgerun.com
Developers wiki: https://developer.ridgerun.com
Website: https://www.ridgerun.com/

1 Like

Hi @oscar.fallas

Here is the log :
vi.log (70.6 KB)

Thanks

Boost the clocks to try.

sudo su
echo 1 > /sys/kernel/debug/bpmp/debug/clk/vi/mrq_rate_locked
echo 1 > /sys/kernel/debug/bpmp/debug/clk/isp/mrq_rate_locked
echo 1 > /sys/kernel/debug/bpmp/debug/clk/nvcsi/mrq_rate_locked
echo 1 > /sys/kernel/debug/bpmp/debug/clk/emc/mrq_rate_locked
cat /sys/kernel/debug/bpmp/debug/clk/vi/max_rate |tee /sys/kernel/debug/bpmp/debug/clk/vi/rate
cat /sys/kernel/debug/bpmp/debug/clk/isp/max_rate | tee  /sys/kernel/debug/bpmp/debug/clk/isp/rate
cat /sys/kernel/debug/bpmp/debug/clk/nvcsi/max_rate | tee /sys/kernel/debug/bpmp/debug/clk/nvcsi/rate
cat /sys/kernel/debug/bpmp/debug/clk/emc/max_rate | tee /sys/kernel/debug/bpmp/debug/clk/emc/rate

Hi

I did a clock boost, but the symptoms were the same.

Is there a way to debug vi?

Does the i2c write failed doesn’t matter?

Hi! @rlatae123

Maybe you can check with sudo dmesg | grep tegra-capture to check in the interval of the when the capture is being enabling takes too much time to the first frame arrive. If you check it please upload the log to help you.

Regards,

Oscar Fallas
Embedded SW Engineer at RidgeRun
Contact us: support@ridgerun.com
Developers wiki: https://developer.ridgerun.com
Website: https://www.ridgerun.com/

1 Like

Hi

i2c is a log left for debugging

Hi @oscar.fallas

Here is the log.

log.txt (564 Bytes)

How about skip few frame to dump to check.

It seems the problem is not coming from tegra-capture. Is possible to attach the complete dmesg log?

Regards,

Oscar Fallas
Embedded SW Engineer at RidgeRun
Contact us: support@ridgerun.com
Developers wiki: https://developer.ridgerun.com
Website: https://www.ridgerun.com/

Hi, @oscar.fallas

Here is dmesg log:
result.txt (62.0 KB)

you mean about the v4l2-ctl stream-skip option?

I tried it but the symptoms are the same.

Is there another way to skip?

Hi @rlatae123

Sorry for the delayed response, I could not find something related to the issue on the dmesg log. We can maybe trying to debug into the max9296 driver, more specifically look where the driver is trying to write 0x08 into the dev address 0x313, this failed write could be causing a delayed on the bring up of the sensor and doing tegra-capture-vi discards the frame 0.

Thanks,

Oscar Fallas
Embedded SW Engineer at RidgeRun
Contact us: support@ridgerun.com
Developers wiki: https://developer.ridgerun.com
Website: https://www.ridgerun.com/

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