Orin jp5.1.1, camera error when I capture Image


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!


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

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?


hello nvidias,

please gather the complete failures for reference, thanks

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.

Dmesg.log (101.4 KB)
Trace.log (124.5 KB)

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
  1. 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.

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.


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

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.

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?


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


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.

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