Orin jp5.1.1, camera error when I capture Image

[nvidias]

Hello,

I use 1 max9296+ 2 max9295 , 1920x1536 ,30fps , whit gmsl2, my configuration is normal on Xavier with jp4.6, but the following error is reported on ORIN whit jp5.1.1, dmesg :

trace :
trace.txt (11.9 KB)

this trace is replace “camera-rtcpu-t234-rce.img” whit topic I found mipi data,but soc cann't get these frame - #12 by ShaneCCC

On the forums I noticed that some people also encountered this problem, mostly saying that pix_clk_hz and serdes_pix_clk_hz did not match. I tried several things but failed.

Please help me to diagnose the cause of this problem, thanks!

Thanks!
BR,

[JerryChang]

hello nvidias,

please do not replace that debug firmware since it’s not compatible with JP-5.1.1/l4t-r35.3.1

may I know what’s your output data rate.
skew calibration is required if sensor or deserializer is using DPHY, and the output data rate is > 1.5Gbps.
you may see-also SerDes Pixel Clock for details. thanks

[nvidias]

Hi JerryChang,

Thanks for your reply!
okay,I have changed back to the official version of r35.3.1

Now the question is: what could possibly be the reason why I can get the stream when I open it properly the first time, but I can’t get the stream when I open it again after closing it?
How can I fix it?

Thanks!

[JerryChang]

@nvidias

but I can’t get the stream when I open it again after closing it?

hello nvidias,

please gather the complete failures for reference, thanks

[nvidias]

Hi JerryChang,

Thanks for your reply!

I use jetson orin with 8core + 32GB memory :
1). When starting up, I used the command “v4l2-ctl --device /dev/video0 --stream-mmap --set-fmt-video=width=1920,height=1536,pixelformat=UYVY” to catch the data, then I stopped and ran the command again, but at this point I couldn’t catch any data.
2). The “Demsg.log” and “Trace.log” of the whole process are shown in the attachment.
In the dmesg, I noticed that there was a “CPU:0, Error: cbb-fabric@0x13a00000, irq=34” error, I don’t know if this error affects.

Thanks!
B.R,
Dmesg.log (101.4 KB)
Trace.log (124.5 KB)

[JerryChang]

hello nvidias,

1. how you terminate v4l pipeline, are you using ctrl^c to shut it down?
   could you please have another test by adding --stream-count=30 for the pipeline to capture 30-frames and then close the camera stream gracefully.

2. it is slave error, which may due to no power-up as an invalid access.
   since you’re able to enable the stream for testing. you may ignore these cbb-fabric errors at the moment.

[   13.272980] CPU:0, Error:cbb-fabric, Errmon:2
[   13.272985] 	  Error Code		: SLAVE_ERR
[   13.278564] vdd-dp: supplied by vdd-3v3-sys
[   13.284044] 	  Overflow		: Multiple SLAVE_ERR

[   13.289326] vdd-3v3-sd: supplied by vdd-3v3-sys
[   13.293665] 	  Error Code		: SLAVE_ERR

3. according to below… it’s your 2nd to access the stream.

[ 1092.216169] video0: VIDIOC_G_FMT: type=vid-cap, width=1920, height=1536, pixelformat=UYVY, field=none, bytesperline=3840, sizeimage=5898240, colorspace=8, flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0
[ 1094.804151] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 2500 ms
[ 1094.813299] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: attempting to reset the capture channel
[ 1094.823384] (NULL device *): vi_capture_control_message: NULL VI channel received

as you can see, it’s capture engine to wait till 2500ms timeout. the logs from VI tracing shown there’s no frame signals, i.e. SOF/EOF…etc;
please double check your power sequence. this may to due to you’ve incorrect stream-on/off sequence.

[nvidias]

Hi JerryChang,

Thanks for your reply again!

1. yes，I use ctrl^c to shut it down. I will add “–stream-count=30” to try again.
2. How can "cbb-fabric error" be fixed? I use 8cores + 32GB memory

I use command “v4l2-ctl --device /dev/video0 --stream-mmap --set-fmt-video=width=1920,height=1536,pixelformat=UYVY --stream-count=30” to try again as shown below pic:

The “dmesg.log” and “trace.log” of the whole process are shown in the attachment.

Thanks!
B.R,

trace.log (113.3 KB)
dmesg.log (104.4 KB)

[JerryChang]

hello nvidias,

it looks like camera did not output frames for your 2nd trail.
do you have implement reset mechanism for this SerDes chip, you may try sending a reset before s_stream.

[nvidias]

Hi JerryChang,

Thanks for your reply !

The second time to take the data stream, the Des MAX9296 is output signal, measured by oscilloscope,but the VI message indicates that the stream cannot be fetched.

So, I think 9296 has been sending streams, but SOC can’t get streams for some reason?

Thanks!
B.R,

[nvidias]

I think， there may be some mismatch between the parameter settings of "pix_clk_hz"and “serdes_pix_clk_hz”，but I don’t know how to correctly configure it according to the serdes-pixel-clock

Are there any empirical values for reference?
I use : max9296+2max9295+2isx031, 1920x1536 @30fps

Thanks!

[JerryChang]

hello nvidias,

according to the VI tracing logs, there’s not shown frame signals, especially start-of-frame and end-of-frame. that’s why VI reporting timeout errors.
do you sending a reset before s_stream? this approach sometime able to fix stream stability issues.

do you know deserializer output data rate?
here’s formula… serdes_pix_clk_hz = (deserializer output data rate in hertz) * (number of CSI lanes) / (bits per pixel)
you may also check Sensor Pixel Clock for several approaches to evaluate sensor pixel clock rate.