Custom CSI camera frames contain only zeros

Autonomous Machines Jetson & Embedded Systems Jetson Nano
1

I am implementing a driver for a CSI camera, and I am having issues with all frames I capture containing only zeros when I use the following command:

v4l2-ctl --set-fmt-video=width=1920,height=1080,pixelformat=RG10 --stream-mmap --set-ctrl=bypass_mode=0 --stream-count=3 -d /dev/video0 --stream-to=test_cam_data --verbose

hexdump -C test_cam_data
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |…|
*
00d72b00

I was wondering if this issue may also be related to a discrepancy between the clocks my camera generates, and those expected by the jetson.

When comparing to a Raspberry Pi camera on a scope I notice 1V2 pulses at the frequency of the frame rate. I do not see these pulses on the custom camera. I believe the custom camera just outputs clock continuously, rather than changing to low power mode between frames.

scope_clock_sync_pulses
scope_clock_sync_pulses800×480 85.4 KB

The device tree files have a discontinuous_clk setting. Which in the case of the IMX219 is set to “yes”. Should this be set to “no” in the case where the sensor continuously outputs a clock? and would this be causing my issue?

I get the following errors when the debug settings from https://elinux.org/Jetson_TX2_Camera_BringUp are enabled

[ 1182.369724] video4linux video0: Syncpoint already enabled at capture done!0
[ 1182.572133] video4linux video0: tegra_channel_capture_done: MW_ACK_DONE syncpoint time out!0
[ 1182.580901] video4linux video0: TEGRA_VI_CSI_ERROR_STATUS 0x00000004
[ 1182.580951] vi 54080000.vi: TEGRA_CSI_PIXEL_PARSER_STATUS 0x00000080
[ 1182.580990] vi 54080000.vi: TEGRA_CSI_CIL_STATUS 0x00000000
[ 1182.581029] vi 54080000.vi: TEGRA_CSI_CILX_STATUS 0x00000000
[ 1182.581209] vi 54080000.vi: cil_settingtime was autocalculated
[ 1182.581222] vi 54080000.vi: csi clock settle time: 13, cil settle time: 10

and a trace says this:

vi-output, cam1-18493 [001] … 1182.302335: tegra_channel_capture_frame: sof:1182.178411609
vi-output, cam1-18493 [001] … 1182.336534: tegra_channel_capture_frame: sof:1182.212188026
vi-output, cam1-18493 [001] … 1182.369693: tegra_channel_capture_frame: sof:1182.245776157
v4l2-ctl-18492 [000] … 1182.581303: tegra_channel_capture_done: mw_ack_done:0.22894443866

Do I need low frequency pulses on the clock line? How would I verify if data is being recieved through the MIPI interface, regardless if the images are the correct size, or data type.

The sensor I am using outputs in RAW8 and RAW10. How can I configure the device tree for these transfer formats?.

3

Have a check the TRM for the REG CSI_CSI_PIXEL_PARSER_A_STATUS_0
It tell the short frame error that mean the sensor output size didn’t as expect.

PPA_SHORT_FRAME: Set when CSI-PPA receives a short frame. This bit gets set even if
CSI_PPA_PAD_FRAME specifies that short frames are to be padded to the correct line length.

4

Just to confirm, is the correct TRM for the Jetson Nano, the TRM for the TX1?

From the information you have provided, it seems that I have a short frame error. How do I check if there is any data in the frame?

Also is the discontinuous_clk setting in the device tree, for situations where the camera doesn’t leave high speed mode, such as described above?

5

Fixed ths short frame problem should be able get the data from your command,
discontinuous_clk means the clock doesn’t leave high speed mode.

6

Thanks for the responses. What are the possible causes of a short frame on the jetson configuration side of things? I am reasonably confident that camera is outputting correctly if a continuous clock is acceptable.

I have taken the values for: pix_clk_hz and line_length directly from the sensor. The sensor board uses a 12MHz external clock, so I have tried configuring mclk_khz = “12000”;

I believe the sensor outputs in a RAW10 format, as such I have implemented the patch from https://forums.developer.nvidia.com/t/how-to-display-grayscale-camera/80503/4 is this necessary to get output from a RAW streaming mono camera?

7

The short frame error doesn’t matter with the continuous clocks.
It’s the sensor output less line than the driver report. You can modify the sensor driver or device tree to report less height and active_h in device tree to try.

8

Thanks for the help Shane, I believe my issues are resolved.