Hi @ShaneCCC
I have connected the IMX334 sensor to Serdes setup , but when I do i2cdetect i could not find the address of the sensor .
What might be the reason?
Note:
I could find the address of IMX477 sensor , the issue is when IMX334 is connected.
Please check with the HW design to confirm if any power/reset/standby pin need to config to make sensor working to ack the i2c command.
Hi @ShaneCCC
tevs 12-0048: Cannot get standby GPIO (-121)
[ 55.346461] tevs 12-0048: tevs setup failed
[ 55.346655] tevs: probe of 12-0048 failed with error -22
any idea about this error?
Hi @ShaneCCC
-
Can you explain the importance of power/reset/standby pin in the case of i2c detection?
Especially on the reset, can you elaborate? -
Cannot standby GPIO error relationship to the above query
Please check with HW design to make sure those pins in device tree and driver control.
I could see the stream now , but hanging after certain time with the below errors on dmesg
[RCE] ERROR: camera-ip/nvcsi/nvcsi.c:1984 [nvcsi_stream_set_config] "MIPI clock rate not known. Using 250000 kHz
[ 716.129484] [RCE] "
[ 724.156254] tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 0, flags: 0, err_data 4194400
[ 724.243772] tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 0, flags: 0, err_data 4194400
[ 724.943726] tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 0, flags: 0, err_data 4194400
The below errors in the trace
198.587190: rtcpu_vinotify_event: tstamp:6972911602 cch:0 vi:0 tag:CHANSEL_NOMATCH channel:0x01 frame:0 vi_tstamp:223124047072 data:0x00000000000003c9
kworker/3:3-190 [003] .... 198.643183: rtcpu_vinotify_event: tstamp:6975285165 cch:0 vi:0 tag:FE channel:0x00 frame:0 vi_tstamp:223208101408 data:0x0000000000000020
kworker/3:3-190 [003] .... 198.643185: rtcpu_vinotify_error: tstamp:6975361966 cch:0 vi:0 tag:CHANSEL_NOMATCH channel:0x01 frame:0 vi_tstamp:223211545376 data:0x00000000000003c9
kworker/3:3-190 [003] .... 198.643186: rtcpu_vinotify_event: tstamp:6975624314 cch:0 vi:0 tag:FS channel:0x00 frame:0 vi_tstamp:223211506368 data:0x0000000000000010
kworker/3:3-190 [003] .... 198.643187: rtcpu_vinotify_event: tstamp:6975624459 cch:0 vi:0 tag:CHANSEL_NOMATCH channel:0x01 frame:0 vi_tstamp:223211545376 data:0x00000000000003c9
kworker/3:3-190 [003] .... 198.755256: rtcpu_vinotify_event: tstamp:6977997767 cch:0 vi:0 tag:FE channel:0x00 frame:0 vi_tstamp:223295599744 data:0x0000000000000020
kworker/3:3-190 [003] .... 198.755260: rtcpu_vinotify_error: tstamp:6978096288 cch:0 vi:0 tag:CHANSEL_NOMATCH channel:0x01 frame:0 vi_tstamp:223299043648 data:0x00000000000003c9
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
I tried boosting the clocks , still faced the same errors
By the way what actually boosting the clock does,technically ?
Format Video Capture:
Width/Height : 2592/1944
Pixel Format : 'UYVY' (UYVY 4:2:2)
Field : None
Bytes per Line : 5184
Size Image : 10077696
Colorspace : sRGB
Transfer Function : Default (maps to sRGB)
YCbCr/HSV Encoding: Default (maps to ITU-R 601)
Quantization : Default (maps to Limited Range)
Flags :
Camera Controls
sensor_configuration 0x009a2032 (u32) : min=0 max=4294967295 step=1 default=0 [22] flags=read-only, volatile, has-payload
sensor_mode_i2c_packet 0x009a2033 (u32) : min=0 max=4294967295 step=1 default=0 [1026] flags=read-only, volatile, has-payload
sensor_control_i2c_packet 0x009a2034 (u32) : min=0 max=4294967295 step=1 default=0 [1026] flags=read-only, volatile, has-payload
bypass_mode 0x009a2064 (intmenu): min=0 max=1 default=0 value=0
0: 0 (0x0)
1: 1 (0x1)
override_enable 0x009a2065 (intmenu): min=0 max=1 default=0 value=0
0: 0 (0x0)
1: 1 (0x1)
height_align 0x009a2066 (int) : min=1 max=16 step=1 default=1 value=1
size_align 0x009a2067 (intmenu): min=0 max=2 default=0 value=0
0: 1 (0x1)
1: 65536 (0x10000)
2: 131072 (0x20000)
write_isp_format 0x009a2068 (int) : min=1 max=1 step=1 default=1 value=1
sensor_signal_properties 0x009a2069 (u32) : min=0 max=4294967295 step=1 default=0 [30][18] flags=read-only, has-payload
sensor_image_properties 0x009a206a (u32) : min=0 max=4294967295 step=1 default=0 [30][16] flags=read-only, has-payload
sensor_control_properties 0x009a206b (u32) : min=0 max=4294967295 step=1 default=0 [30][36] flags=read-only, has-payload
sensor_dv_timings 0x009a206c (u32) : min=0 max=4294967295 step=1 default=0 [30][16] flags=read-only, has-payload
low_latency_mode 0x009a206d (bool) : default=0 value=0
preferred_stride 0x009a206e (int) : min=0 max=65535 step=1 default=0 value=0
sensor_modes 0x009a2082 (int) : min=0 max=30 step=1 default=30 value=4 flags=read-only
Then, the trace log show the CHANSEL_NOMATCH could cause by the incorrect embedded_data_height in the device tree.
I checked changing this value(embedded data height) still could see it
0x00000000000003c9
what does this error mean?
Make sure the embedded lines to set the embedded_data_height.
If still the same it could be the incorrect virtual channel ID in package.
Working fine when I connect directly to Xavier , the error occurs when I am using it in Serdes setup using GMSL protocol
Hi @ShaneCCC ,
My sensor throws YUV(4:2:2) format , from the error (3c9) it shows that the deserializer is unable to give the same format to Soc so it is not able to understand .Is my understanding correct?
This tell the GMSL output some unknow package cause the problem.
Does the NOMATCH show without the GMSL?
Hi @ShaneCCC ,
No such error without GMSL
This tell the GMSL output some unknow package cause the problem.
what kind of package do you mean?Any suggestions
Hi @oscar.fallas ,
any thoughts on the issue ?
HI @ShaneCCC
any fix from your side for this error in 35.4.1 version,Xavier series
[RCE] VM0 deactivating.VM0 activating.ERROR: camera-ip/nvcsi/nvcsi.c:1984 [nvcsi_stream_set_config] "MIPI clock rate not known. Using 250000 kHz
And any suggestions about the GMSL package ?
Make sure the pix_clk_hz is report in the device tree of sensor mode# scope.
yes it is already present
mode3 { /* AP1302_MODE_1920x1080_30FPS */
mclk_khz = "24000";
num_lanes = "2";
tegra_sinterface = "serial_a";
phy_mode = "DPHY";
discontinuous_clk = "yes";
dpcm_enable = "false";
cil_settletime = "0";
active_w = "3840";
active_h = "2160";
pixel_t = "yuv_uyvy";
csi_pixel_bit_depth = "16";
dynamic_pixel_bit_depth = "16";
readout_orientation = "90";
line_length = "1280";
inherent_gain = "1";
mclk_multiplier = "9.33";
pix_clk_hz = "182400000";
Should configurate it during power on or streaming on.