Hi
I am getting an error as shown in the link below. I followed the solution but the error still occurs.
Suppose it could be your sensor take much time to initial cause the first capture failed. Maybe try more time or -1
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.
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
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/
system
Closed
November 20, 2024, 2:56am
22
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.