Camera captures only zeros rgb565

Trying to capture rgb565 data from camera, but all it captures are zero’s
v4l2-ctl --verbose --device /dev/video1 --stream-mmap --stream-to=frame.raw --stream-count=10

First started with yuv422 and that worked fine.
Next changed dts modes and camera settings, but now it captures at the correct rate, but all zero’s.
Measured and the camera seems to output the correct data (rgb565). Timings are the same because both 2 bytes/pixel.
Any pointers on where to add more logging to see what’s going on? Seems that it’s ok for the CSI, except for the first frame.

[  786.829215] vi tegra_csi_error TEGRA_CSI_PIXEL_PARSER_STATUS 0x00000000
[  786.836959] vi tegra_csi_error TEGRA_CSI_CIL_STATUS 0x00000012
[  786.844426] vi tegra_csi_error TEGRA_CSI_CILX_STATUS 0x00060041
[  786.851506] vi tegra_channel_error_status:error 20002 frame 0
[  786.858577] video4linux video1: free_ring_buffers: capture init latency is 2552 ms
[  786.902337] vi tegra_csi_error TEGRA_CSI_PIXEL_PARSER_STATUS 0x00000000
[  786.912988] vi tegra_csi_error TEGRA_CSI_CIL_STATUS 0x00000000
[  786.920593] vi tegra_csi_error TEGRA_CSI_CILX_STATUS 0x00000000
[  786.938906] vi tegra_csi_error TEGRA_CSI_PIXEL_PARSER_STATUS 0x00000000
[  786.946807] vi tegra_csi_error TEGRA_CSI_CIL_STATUS 0x00000000
[  786.954130] vi tegra_csi_error TEGRA_CSI_CILX_STATUS 0x00000000
[  786.975952] vi tegra_csi_error TEGRA_CSI_PIXEL_PARSER_STATUS 0x00000000
[  786.983848] vi tegra_csi_error TEGRA_CSI_CIL_STATUS 0x00000000
[  786.990959] vi tegra_csi_error TEGRA_CSI_CILX_STATUS 0x00000000
cap dqbuf: 1 seq:      1 bytesused: 614400 ts: 786.446225 (ts-monotonic, ts-src-eof)
[  787.012046] vi tegra_csi_error TEGRA_CSI_PIXEL_PARSER_STATUS 0x00000000
[  787.019973] vi tegra_csi_error TEGRA_CSI_CIL_STATUS 0x00000000
[  787.027208] vi tegra_csi_error TEGRA_CSI_CILX_STATUS 0x00000000
cap dqbuf: 2 seq:      2 bytesused: 614400 ts: 786.482763 delta: 36.538 ms (ts-monotonic, ts-src-eof)
[  787.048648] vi tegra_csi_error TEGRA_CSI_PIXEL_PARSER_STATUS 0x00000000
[  787.056544] vi tegra_csi_error TEGRA_CSI_CIL_STATUS 0x00000000
[  787.063612] vi tegra_csi_error TEGRA_CSI_CILX_STATUS 0x00000000
cap dqbuf: 3 seq:      3 bytesused: 614400 ts: 786.519718 delta: 36.955 ms (ts-monotonic, ts-src-eof)
[  787.085537] vi tegra_csi_error TEGRA_CSI_PIXEL_PARSER_STATUS 0x00000000
[  787.093649] vi tegra_csi_error TEGRA_CSI_CIL_STATUS 0x00000000
[  787.100774] vi tegra_csi_error TEGRA_CSI_CILX_STATUS 0x00000000
cap dqbuf: 0 seq:      4 bytesused: 614400 ts: 786.555912 delta: 36.194 ms (ts-monotonic, ts-src-eof)
[  787.121746] vi tegra_csi_error TEGRA_CSI_PIXEL_PARSER_STATUS 0x00000000
[  787.129972] vi tegra_csi_error TEGRA_CSI_CIL_STATUS 0x00000000
[  787.137061] vi tegra_csi_error TEGRA_CSI_CILX_STATUS 0x00000000
cap dqbuf: 1 seq:      5 bytesused: 614400 ts: 786.592486 delta: 36.574 ms fps: 27.35 (ts-monotonic, ts-src-eof)
[  787.158245] vi tegra_csi_error TEGRA_CSI_PIXEL_PARSER_STATUS 0x00000000
[  787.166539] vi tegra_csi_error TEGRA_CSI_CIL_STATUS 0x00000000
[  787.174256] vi tegra_csi_error TEGRA_CSI_CILX_STATUS 0x00000000
cap dqbuf: 2 seq:      6 bytesused: 614400 ts: 786.629149 delta: 36.663 ms fps: 27.33 (ts-monotonic, ts-src-eof)
[  787.194857] vi tegra_csi_error TEGRA_CSI_PIXEL_PARSER_STATUS 0x00000000
[  787.204090] vi tegra_csi_error TEGRA_CSI_CIL_STATUS 0x00000000
[  787.211132] vi tegra_csi_error TEGRA_CSI_CILX_STATUS 0x00000000
cap dqbuf: 3 seq:      7 bytesused: 614400 ts: 786.665560 delta: 36.411 ms fps: 27.36 (ts-monotonic, ts-src-eof)
[  787.231397] vi tegra_csi_error TEGRA_CSI_PIXEL_PARSER_STATUS 0x00000000
[  787.240963] vi tegra_csi_error TEGRA_CSI_CIL_STATUS 0x00000000
[  787.248023] vi tegra_csi_error TEGRA_CSI_CILX_STATUS 0x00000000
cap dqbuf: 0 seq:      8 bytesused: 614400 ts: 786.702130 delta: 36.570 ms fps: 27.35 (ts-monotonic, ts-src-eof)
[  787.268006] vi tegra_csi_error TEGRA_CSI_PIXEL_PARSER_STATUS 0x00000000
[  787.276680] vi tegra_csi_error TEGRA_CSI_CIL_STATUS 0x00000000
[  787.283767] vi tegra_csi_error TEGRA_CSI_CILX_STATUS 0x00000000
cap dqbuf: 1 seq:      9 bytesused: 614400 ts: 786.738722 delta: 36.592 ms fps: 27.35 (ts-monotonic, ts-src-eof)
[  787.304612] vi tegra_csi_error TEGRA_CSI_PIXEL_PARSER_STATUS 0x00000000
[  787.312875] vi tegra_csi_error TEGRA_CSI_CIL_STATUS 0x00000000
[  787.320650] vi tegra_csi_error TEGRA_CSI_CILX_STATUS 0x00000000
cap dqbuf: 2 seq:     10 bytesused: 614400 ts: 786.775277 delta: 36.555 ms fps: 27.35 (ts-monotonic, ts-src-eof)
[  787.341092] vi tegra_csi_error TEGRA_CSI_PIXEL_PARSER_STATUS 0x00000000
[  787.348856] vi tegra_csi_error TEGRA_CSI_CIL_STATUS 0x00000000
[  787.355927] vi tegra_csi_error TEGRA_CSI_CILX_STATUS 0x00000000
[  787.363112] video4linux video1: Syncpoint already enabled at capture done!0
[  787.374419] ov5640 6-003c: v4l2sd_stream++ enable 0

hello Sbuteo,

it seems frames were processed correctly according to the logs.
those CSI registers, such as TEGRA_CSI_PIXEL_PARSER_STATUS, and TEGRA_CSI_CIL_STATUS also shows 0x0 means error free from CSI side.

since you’d configure sensor as rgb565, you may also extend the VI support formats.
for example,

static const struct camera_common_colorfmt camera_common_color_fmts[] 

please also update below kernel calls to report its fourcc types to linux kernel.
for example,

static int extract_pixel_format(
        const char *pixel_t, u32 *format)

Thanks JerryChang,

Already did that. So logging and results are with this patch add-missing-video-formats.patch.txt. Remark, I also needed to add RGB888 to support another camera (which by the way, works correct).
So or
my additions are incorrect
I need a way to find out where the data is dropped (2.5 KB)

hello Sbuteo,

it seems you’re report RGB888 as ABGR32 for its fourcc.
there’re some similar discussion threads, such as Topic 80050, and Topic 74804.
VI did not support RGB888 memory formats due to it’ll also need luminance formats.

since we have never test with RGB565 sensors before,
may I know what’s your use-case, thanks

Hi JerryChang,

We have 2 camera’s. One comming from an FGPA that sends parallel data that is converted to RGB888 mipi.
but RGB888 is not a problem. That data we can capture perfectly.

Another datastream is comming from a real camera that send RGB565. A first test was done with YUV422 on that camera and that worked correct. But the customer wants RGB565. Hence we adjusted the camera and added common_camera and common_sensor adaptations. But with the know zero results.

Will look into the topics you give. Some of the topics that there already pointed to, we investigated already.
Any pointer on how to investigate where the data is lost would be great.

A little bit further.
If I disable BYPASS_PXL_TRANSFORM in VI_CSI_0_IMAGE_DEF_0, I get data from the camera, but nog correct at the moment (I think).

hello Sbuteo,

trigger this will bypass VI engine to skip pixel transformation into I.F format.
to confirm the data, you may dump the raw file and using 3rd party tools, such as 7yuv to examine the content.

Was already looking at a hexeditor.
Seems that the driver of the Nano doesn’t support RGB565. You need also to add it like below (and also the above patch):
if (chan->pg_mode ||
(chan->write_ispformat == TEGRA_ISP_FORMAT) ||
(chan->fmtinfo->vf_code == TEGRA_VF_YUV422) ||
- (chan->fmtinfo->vf_code == TEGRA_VF_RGB888))
+ (chan->fmtinfo->vf_code == TEGRA_VF_RGB888) ||
+ (chan->fmtinfo->vf_code == TEGRA_VF_RGB565)
+ )