Error while setting up camera

Autonomous Machines Jetson & Embedded Systems Jetson AGX Xavier
1

Hello,

I’m using a camera that sends YUV422 8-bit data over MIPI. I’m encountering an issue while trying to capture image using yavta -c /dev/video0.

This is the error log:

[  389.299296] tegra194-vi5 15c10000.vi: no reply from camera processor
[  389.299466] tegra194-vi5 15c10000.vi: uncorr_err: request timed out after 2500 ms
[  389.299618] tegra194-vi5 15c10000.vi: err_rec: attempting to reset the capture channel
[  389.308648] scare-pigeon 13e10000.host1x:vi-thi@15f00000: nvhost_syncpt_get_cv_dev_address_table: failed to fetch_cv_dev_info
[  389.309384] tegra194-vi5 15c10000.vi: err_rec: successfully reset the capture channel
[  391.859242] tegra194-vi5 15c10000.vi: no reply from camera processor
[  391.859431] tegra194-vi5 15c10000.vi: uncorr_err: request timed out after 2500 ms
[  391.859574] tegra194-vi5 15c10000.vi: err_rec: attempting to reset the capture channel
[  391.861663] scare-pigeon 13e10000.host1x:vi-thi@15f00000: nvhost_syncpt_get_cv_dev_address_table: failed to fetch_cv_dev_info
[  391.862120] tegra194-vi5 15c10000.vi: err_rec: successfully reset the capture channel
[  394.387164] tegra194-vi5 15c10000.vi: no reply from camera processor
[  394.387319] tegra194-vi5 15c10000.vi: uncorr_err: request timed out after 2500 ms
[  394.387472] tegra194-vi5 15c10000.vi: err_rec: attempting to reset the capture channel
[  394.390705] scare-pigeon 13e10000.host1x:vi-thi@15f00000: nvhost_syncpt_get_cv_dev_address_table: failed to fetch_cv_dev_info
[  394.391213] tegra194-vi5 15c10000.vi: err_rec: successfully reset the capture channel

Here is the rtcpu log from tracing enabled (I didn’t enable freertos tracing because that was unnecessary noise):

     kworker/0:0-4     [000] ....   386.787361: rtcpu_string: tstamp:12282891836 id:0x04010000 str:"on 2.2
"
     kworker/0:0-4     [000] ....   386.787518: rtcpu_vinotify_event: tstamp:12283206053 tag:RESERVED_18 channel:0x23 frame:0 vi_tstamp:10801825088 data:0x10000000
     kworker/0:0-4     [000] ....   386.787520: rtcpu_vinotify_event: tstamp:12283206554 tag:RESERVED_18 channel:0x23 frame:0 vi_tstamp:10801832096 data:0x31000001
     kworker/0:0-4     [000] ....   386.787522: rtcpu_vinotify_event: tstamp:12283207169 tag:RESERVED_19 channel:0x23 frame:0 vi_tstamp:10801833088 data:0x07020001
     kworker/0:0-4     [000] ....   386.787523: rtcpu_vinotify_event: tstamp:12283207669 tag:RESERVED_18 channel:0x23 frame:0 vi_tstamp:10801902688 data:0x10000000
     kworker/0:0-4     [000] ....   386.787524: rtcpu_vinotify_event: tstamp:12283208284 tag:RESERVED_18 channel:0x23 frame:0 vi_tstamp:10801909728 data:0x31000002
     kworker/0:0-4     [000] ....   386.787555: rtcpu_nvcsi_intr: tstamp:12283579638 class:GLOBAL type:PHY_INTR0 phy:1 cil:0 st:0 vc:0 status:0x00000089
     kworker/0:0-4     [000] ....   386.787557: rtcpu_nvcsi_intr: tstamp:12283579638 class:GLOBAL type:PHY_INTR0 phy:1 cil:1 st:0 vc:0 status:0x00000088
 vi-output, ar02-22002 [001] ....   389.308595: tegra_channel_capture_setup: vnc_id 0 W 1928 H 1208 fmt 13
     kworker/0:0-4     [000] ....   389.375322: rtcpu_vinotify_event: tstamp:12363431217 tag:RESERVED_18 channel:0x23 frame:0 vi_tstamp:13368047200 data:0x10000000
     kworker/0:0-4     [000] ....   389.375329: rtcpu_vinotify_event: tstamp:12363431418 tag:RESERVED_18 channel:0x23 frame:0 vi_tstamp:13368051104 data:0x31000001
     kworker/0:0-4     [000] ....   389.375330: rtcpu_vinotify_event: tstamp:12363431570 tag:RESERVED_19 channel:0x23 frame:0 vi_tstamp:13368052096 data:0x07020001
     kworker/0:0-4     [000] ....   389.375332: rtcpu_vinotify_event: tstamp:12363431741 tag:RESERVED_18 channel:0x23 frame:0 vi_tstamp:13368088768 data:0x10000000
     kworker/0:0-4     [000] ....   389.375333: rtcpu_vinotify_event: tstamp:12363431886 tag:RESERVED_18 channel:0x23 frame:0 vi_tstamp:13368092672 data:0x31000002
 vi-output, ar02-22002 [000] ....   391.861617: tegra_channel_capture_setup: vnc_id 0 W 1928 H 1208 fmt 13
     kworker/0:0-4     [000] ....   391.871182: rtcpu_vinotify_event: tstamp:12443033393 tag:RESERVED_18 channel:0x23 frame:0 vi_tstamp:11625804544 data:0x10000000
     kworker/0:0-4     [000] ....   391.871187: rtcpu_vinotify_event: tstamp:12443033549 tag:RESERVED_18 channel:0x23 frame:0 vi_tstamp:11625808416 data:0x31000001
     kworker/0:0-4     [000] ....   391.871188: rtcpu_vinotify_event: tstamp:12443033743 tag:RESERVED_19 channel:0x23 frame:0 vi_tstamp:11625809408 data:0x07020001
     kworker/0:0-4     [000] ....   391.871190: rtcpu_vinotify_event: tstamp:12443033888 tag:RESERVED_18 channel:0x23 frame:0 vi_tstamp:11625849120 data:0x10000000
     kworker/0:0-4     [000] ....   391.871191: rtcpu_vinotify_event: tstamp:12443034078 tag:RESERVED_18 channel:0x23 frame:0 vi_tstamp:11625853024 data:0x31000002

Please find attached the device tree settings for this camera node:
cam-devnode.dtsi (5.4 KB)

3

hello atharvanandanwar,

it looks you’re using Ser/Des chip. it’s carry over virtual channel for sending MIPI signaling.
this error message… tegra194-vi5 15c10000.vi: no reply from camera processor… it indicate there’s no valid signal received by VI engine. it usually caused by VI engine cannot receive SoF/EoF within timeout limit. (i.e. 2500ms)

in addition, VI tracing logs show there’s PHY interrupts.
such failure means… LP sequence error detected on data lane and also clock lane.
for example,

the other things looks odd is the frame index, it should keep increasing instead of stay at zero.
hence, please review the init settings of your Ser/Des chips. you may also sending a reset signal before start_stream.
thanks

4

Hey Jerry,

Thanks a lot for your input. I was able to be fix few things on the deserializer side, it turns out that if I use a single camera connected - then I am reliably getting the image into the Xavier SOM. Apart from that, what is the significance of pixel_t setting?

Is that an instruction for VI to pack the data into memory in certain format that driver expects or that’s dependent on how the data is received from the bus? We are using MIPI data format 0x1E YUV422 8 bit which comes from 2x lane Serializer → 4x lane Deserializer MIPI link.

Based on the following kernel code fragment from sensor_common.c:

static int extract_pixel_format(
	const char *pixel_t, u32 *format)
{
	size_t size = strnlen(pixel_t, OF_MAX_STR_LEN);

	if (strncmp(pixel_t, "bayer_bggr10", size) == 0)
        /* ...omitted content... */
	else if (strncmp(pixel_t, "yuv_yuyv16", size) == 0)
		*format = V4L2_PIX_FMT_YUYV;
	else if (strncmp(pixel_t, "yuv_yvyu16", size) == 0)
		*format = V4L2_PIX_FMT_YVYU;
	else if (strncmp(pixel_t, "yuv_uyvy16", size) == 0)
		*format = V4L2_PIX_FMT_UYVY;
	else if (strncmp(pixel_t, "yuv_vyuy16", size) == 0)
		*format = V4L2_PIX_FMT_VYUY;
	else if (strncmp(pixel_t, "uyvy", size) == 0)
       *format = V4L2_PIX_FMT_UYVY;
	else if (strncmp(pixel_t, "rgb3", size) == 0)
       *format = V4L2_PIX_FMT_RGB24;
	else {
		pr_err("%s: Need to extend format%s\n", __func__, pixel_t);
		return -EINVAL;
	}

	return 0;
}

What is the difference in these formats from VI perspective and how it will pack the pixel data it receives in the memory? What I’m asking for is - what are we doing when reading pixel_t setting (or pixel_phase, mode_type, csi_pixel_bit_depth setting in the device tree with respect to VI and NVCSI subsystems (and not V4L2 subsystem)?

I was also curious if I would be able to get a reference on how to decode the rtcpu messages. Ex. PHY_INTR0 is a message that I don’t see in Jetson/l4t/Camera BringUp - eLinux.org link that is used to enable rtcpu tracing.

Along with that, I appreciate your speedy response! Thanks a lot!

EDIT: I’m currently looking at Xavier SOC Technical Reference Manual. I think it would be great if the link above would link to the TRM page numbers for respective SOM - so people can go in and read.

5

hello atharvanandanwar,

  1. please refer to Sensor Software Driver Programming. pixel_t has deprecated, it’s replaced by mode_type, csi_pixel_bit_depth and pixel_phase.

  2. that external wiki page only record some general info, please download Xavier TRM.
    you should see [7.2.1.4.8 NVCSI PHY Registers], it’s around page-1195. for the register description,
    i.e. NVCSI_PHY_0_CILA_INTR_0_STATUS_CILA_0

6

Hey JerryChang,

Thanks a lot for answering.

I have read through the TRM and now the rtcpu messages make more sense than before. I would advice to leave a note regarding “refer to TRM” in the external wiki, just so someone stumbles on it without reading the TRM and get lost trying to figure out what to make of the messages.

Thanks again. Appreciate your help.

We can proceed with closing this.

7

hello atharvanandanwar,

that’s a good suggestion, I’ve add a session to external wiki page to Analysis NVCSI register reporting.

8

Hey JerryChang,

Thanks a lot for adding that in. I would also add a recommendation to read up on the NVCSI and VI functionality to make sense of the image pipeline - that actually makes rtcpu logs very clear.

9

hello atharvanandanwar,

we should kept external wiki page as simple as possible.

there’s learning curve of camera software stack.
users should always check developer guide, Camera Development.
also, the training video, V4L2 Sensor Driver Development Tutorial, to dig into driver implementation.

1 Like
10

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