Minimum height size restricted on Jetson video capture subsystem

Autonomous Machines Jetson & Embedded Systems Jetson Xavier NX
1

Hi all,

We are currently developing a driver for a radar device that uses CSI and it has variable frame configuration. We need to set the frame height size to 1, however, we faced some issues with v4l2-ctl as it continued detecting a height size of 32 despite our attempts to set it to 1 in both the driver and the device tree, our environment setup is the following:

  • Jetson Xavier NX

  • Jetpack 5.0.2

  • Radar driver 16384x1 resolution, RAW8 format

We noticed that there is a TEGRA_MIN_HEIGHT macro (#define TEGRA_MIN_HEIGHT 32U, in the tegra_camera_core.h file) that defines a minimum possible height for the Tegra video input devices.

After change the TEGRA_MIN_HEIGHT to 1 and run tests with:

v4l2-ctl -d /dev/video0 --set-fmt-video=width=16384,height=1,pixelformat=RGGB --set-ctrl bypass_mode=0 --stream-mmap --stream-count=1 --stream-to=test.raw --verbose

we get the following VI trace:

 kworker/2:3-120     [002] ....   489.747823: rtcpu_vinotify_event: tstamp:16048919972 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:513563458944 data:0x0000000031000002
 kworker/2:3-120     [002] ....   492.099847: rtcpu_vinotify_event: tstamp:16122656611 cch:0 vi:0 tag:FS channel:0x00 frame:0 vi_tstamp:515919526592 data:0x0000000000000010
 kworker/2:3-120     [002] ....   492.099850: rtcpu_vinotify_event: tstamp:16122656790 cch:0 vi:0 tag:ATOMP_FS channel:0x00 frame:0 vi_tstamp:515919526688 data:0x0000000800000000
 kworker/2:3-120     [002] ....   492.099851: rtcpu_vinotify_event: tstamp:16122656965 cch:0 vi:0 tag:CHANSEL_PXL_SOF channel:0x23 frame:0 vi_tstamp:515924591392 data:0x0000000000000001
 kworker/2:3-120     [002] ....   492.099852: rtcpu_vinotify_event: tstamp:16122657114 cch:0 vi:0 tag:VIFALC_ACTIONLST channel:0x23 frame:0 vi_tstamp:515924602176 data:0x0000000008020001
 kworker/2:3-120     [002] ....   492.099853: rtcpu_vinotify_event: tstamp:16122657287 cch:0 vi:0 tag:CHANSEL_PXL_EOF channel:0x23 frame:0 vi_tstamp:515924645952 data:0x0000000000000002
 kworker/2:3-120     [002] ....   492.099853: rtcpu_vinotify_event: tstamp:16122657436 cch:0 vi:0 tag:ATOMP_FRAME_DONE channel:0x23 frame:0 vi_tstamp:515924646848 data:0x0000000000000000
 kworker/2:3-120     [002] ....   492.099854: rtcpu_vinotify_event: tstamp:16122657606 cch:0 vi:0 tag:VIFALC_ACTIONLST channel:0x23 frame:0 vi_tstamp:515924676320 data:0x0000000002020001
 kworker/2:3-120     [002] ....   492.099854: rtcpu_vinotify_event: tstamp:16122657754 cch:0 vi:0 tag:CHANSEL_FAULT channel:0x23 frame:0 vi_tstamp:515924705184 data:0x0000000000010040
 kworker/2:3-120     [002] ....   492.099855: rtcpu_vinotify_event: tstamp:16123138534 cch:0 vi:0 tag:VIFALC_ACTIONLST channel:0x23 frame:0 vi_tstamp:515924773824 data:0x0000000001020001
 kworker/2:3-120     [002] ....   494.843830: rtcpu_vinotify_error: tstamp:16208785583 cch:-1 vi:0 tag:CSIMUX_STREAM channel:0x00 frame:0 vi_tstamp:518681015968 data:0x0000000000000001
 kworker/2:3-120     [002] ....   494.843833: rtcpu_vinotify_error: tstamp:16208853528 cch:-1 vi:0 tag:CSIMUX_STREAM channel:0x00 frame:0 vi_tstamp:518683177792 data:0x0000000000000001
 kworker/2:3-120     [002] ....   494.843835: rtcpu_vinotify_event: tstamp:16208860029 cch:0 vi:0 tag:FE channel:0x00 frame:0 vi_tstamp:518680990752 data:0x0000000000000020
 kworker/2:3-120     [002] ....   494.843836: rtcpu_vinotify_event: tstamp:16208860215 cch:0 vi:0 tag:ATOMP_FE channel:0x00 frame:0 vi_tstamp:518680990816 data:0x0000000800000000
 kworker/2:3-120     [002] ....   494.843837: rtcpu_vinotify_event: tstamp:16208860381 cch:-1 vi:0 tag:CSIMUX_STREAM channel:0x00 frame:0 vi_tstamp:518681015968 data:0x0000000000000001
 kworker/2:3-120     [002] ....   494.843838: rtcpu_vinotify_event: tstamp:16208860557 cch:-1 vi:0 tag:CSIMUX_STREAM channel:0x00 frame:0 vi_tstamp:518683177792 data:0x0000000000000001

From this trace we note that the CHANSEL_FAULT is reporting a PIXEL_RUNAWAY (0x0040) error and also reporting the current height of the frame (0x1), do you think this could be related to change of the minimum height in the TEGRA_MIN_HEIGHT?

Regarding these aspects our question is: is it possible to modify this macro without problems or is the restriction actually there due to a hardware limitation?

Also from the trace we note that there is a CSIMUX_FRAME that points to a SPURIOUS_DATA_STREAM_0 issue, so we also wonder if there is a way to filter the data and detect only from a FS to a FE? that would be very useful.

Your ideas and suggestions will be greatly appreciated.

Thanks in advance

3

hello greivin.brenes,

may I also know the Argus daemon logs,
is there a warning messages, such as… effective image region is too small reported?

$ sudo su 
# pkill nvargus-daemon
# export enableCamScfLogs=5
# nvargus-daemon
or.. # nvargus-daemon 2>&1 | tee argus-output.log
4

Hi @JerryChang,

Well, we don’t have Argus daemon logs actually, since we are capturing with v4l2 in RAW8 format, so the data is not going through the ISP, we are using this command for the capture tests:

v4l2-ctl -d /dev/video0 --set-fmt-video=width=16384,height=1,pixelformat=RGGB --set-ctrl bypass_mode=0 --stream-mmap --stream-count=1 --stream-to=test.raw --verbose

5

hello greivin.brenes,

could you please check $ v4l2-ctl --all, may I know what’s the resolution reported by Format Video Capture

7

Hi @JerryChang,

It seems that the change in the TEGRA_MIN_HEIGHT is working, since now we are being able to capture with height=1, the output of v4l2-ctl --all:

Format Video Capture:
	Width/Height      : 16384/1
	Pixel Format      : 'RGGB' (8-bit Bayer RGRG/GBGB)
	Field             : None
	Bytes per Line    : 16384
	Size Image        : 16384
	Colorspace        : sRGB
	Transfer Function : Default (maps to sRGB)
	YCbCr/HSV Encoding: Default (maps to ITU-R 601)
	Quantization      : Default (maps to Full Range)
	Flags             :

The issue was actually due to a configuration mode for the device that did not allow us to capture with the proper height size.

Thanks for the help!

8

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