CSI/VI data transmission error

Robotics & Edge Computing Jetson Systems Jetson AGX Orin
,
1

Currently, when we are debugging the camera, we have encountered an error in the transmission of CSI/VI data.. Could you please help us figure out what caused this error?

image
image1063Ă—420 104 KB

Based on the current issue, I am uploading our current driver and dts files.
dts.txt (8.0 KB)
dummy.c.txt (18.0 KB)
I would like to inquire synchronously. Can the result obtained by the v4l2-ctrl command currently represent that the current data is functional, but just in an incorrect format?
image
image1815Ă—789 189 KB

2

*** Please note that this reply is generated by LLM automatically ***

Based on the provided context, I will attempt to help you troubleshoot the issue with the transmission of CSIVI data on the Jetson AGX Orin.

Firstly, let’s analyze the information provided:

  1. You are experiencing an error in the transmission of CSIVI data.
  2. You have uploaded your current driver and dts files (dtstxt and dummyctxt).
  3. You are inquiring if the result obtained by the v4l2-ctl command currently represents that the current data is functional but just in an incorrect format.

To address your issue, let’s break down the possible causes:

  1. CSI Virtual Channel (VC) configuration: Ensure that the CSI VC configuration is correct in your dts file. The Jetson AGX Orin supports up to 16 virtual channels with ISP or 24 virtual channels without ISP. Verify that the VC configuration matches the number of cameras connected.
  2. CSI lane configuration: Check the CSI lane configuration in your dts file. The Jetson AGX Orin supports x4, x2, or x1 lane configurations. Ensure that the lane configuration matches the camera module’s requirements.
  3. GMSL (Gigabit Multimedia Serial Link) configuration: If you are using a GMSL module, verify that the GMSL configuration is correct in your dts file. The Jetson AGX Orin supports GMSL modules, but the configuration might differ from other modules.
  4. ISP (Image Signal Processor) configuration: Ensure that the ISP configuration is correct in your dts file. The ISP configuration might affect the data format and transmission.
  5. v4l2-ctl command: The v4l2-ctl command can be used to verify if the camera is functional, but the data format might be incorrect. Check the v4l2-ctl output to see if the camera is capturing data, but the format is not correct.

Comparing the Jetson AGX Orin with other Jetson modules:

  • The Jetson AGX Orin has a similar CSI interface to the Jetson AGX Xavier series, but the lane configuration and VC configuration might differ.
  • The Jetson AGX Orin has a different ISP configuration compared to the Jetson Xavier NX series.

To further troubleshoot the issue, I recommend:

  1. Verifying the CSI VC configuration and CSI lane configuration in your dts file.
  2. Checking the GMSL configuration (if applicable).
  3. Ensuring the ISP configuration is correct in your dts file.
  4. Using the v4l2-ctl command to verify if the camera is capturing data, but the format is not correct.
  5. Consulting the Jetson AGX Orin documentation and the NVIDIA Jetson Linux Release Notes for more information on the CSI interface, GMSL, and ISP configuration.

If you are still experiencing issues, please provide more information about your setup, including the camera module, GMSL module (if applicable), and the exact error message you are encountering.

*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***

4

The current hardware environment is Jetson AGX ORIN, with Jetson Linux version 36.4, and the SDK is based on Jetpack 6.1.

5

Currently, we are debugging a non-I2C device that supports MIPI CSI input.
We carried out the following verifications：
1.The front-end measures the MIPI data using an oscilloscope and confirms that there is signal transmission.
2.We stopped the front-end data stream. The v4l2-ctrl tool will immediately report a timeout due to inability to obtain data.

Would you like to know if we currently have a debug method that directly reads from registers, such as having registers that can display the resolution size of the input?

6

Reinstall the driver files and the dts files.
dummy.c.txt (18.0 KB)
dts.txt (8.0 KB)

7

The abnormal situations we can currently anticipate are as follows: Since our current flow is not command-controlled, it is equivalent to the input port continuously sending data. When we issue a command to receive the data, the data sent by CSI at this time is not the frame header. It might be a pixel row in the image. Therefore, we fail to receive a complete picture. Then, the CRC check fails, resulting in an error.

Do we have any way to solve this problem through software means, such as resetting the CSI/VI, or configuring certain CSI-related settings?

9

hello 1191208688,

you may try issue a reset signal to the sensor side when you calling start stream.
please see-also Topic 318537 to debug into discarding frame warning messages.

10

Our current hardware connection only supports MIPI, and it is unable to send control signals to the camera sensor.

11

hello 1191208688,

may I have more details about your sensor hardware configuration,
for instance, is it using a SerDes chip?

12

Yes, we used the serdes chip,
but we will have an SOC in front of it to configure the serdes chip, rather than controlling it through Orin.

13

hello 1191208688,

it’s suggest to have stream initialization after you calling start stream.
so that VI can recognize a frame correctly.

14

We have made similar attempts before but without any effect.
Is there a command specifically for resetting the vi?
Or is there any way to access the debug registers?
For example, through the register, one can view information such as the size and format of the current vi/csi input data.

15

hello 1191208688,

you may give it a try to enable VI tracing logs.
for example,

modprobe rtcpu_debug
echo 1 > /sys/kernel/debug/tracing/tracing_on
echo 30720 > /sys/kernel/debug/tracing/buffer_size_kb
echo 1 > /sys/kernel/debug/tracing/events/tegra_rtcpu/enable
echo 1 > /sys/kernel/debug/tracing/events/freertos/enable
echo 2 > /sys/kernel/debug/camrtc/log-level  
echo > /sys/kernel/debug/tracing/trace
cat /sys/kernel/debug/tracing/trace

let me share VI tracing logs with a success image capture as an example.
here must be one pair of CHANSEL_PXL_SOF/CHANSEL_PXL_EOF to indicate a frame has detected by VI engine.
afterwards, it’s ATOMP_FRAME_DONE to indicate it’s complete writing a frame to memory.

rtcpu_vinotify_event: tstamp:4058867917 cch:-1 vi:0 tag:CSIMUX_STREAM channel:0x00 frame:0 vi_tstamp:129874754944 data:0x0000000000000001
rtcpu_vinotify_event: tstamp:4059206674 cch:0 vi:0 tag:ATOMP_FS channel:0x00 frame:1 vi_tstamp:129891804896 data:0x0000000800000000
rtcpu_vinotify_event: tstamp:4059206818 cch:0 vi:0 tag:CHANSEL_PXL_SOF channel:0x23 frame:1 vi_tstamp:129891808928 data:0x0000000000000001
rtcpu_vinotify_event: tstamp:4059206976 cch:0 vi:0 tag:VIFALC_ACTIONLST channel:0x23 frame:1 vi_tstamp:129891815424 data:0x0000000008020001
rtcpu_vinotify_error: tstamp:4060164160 cch:0 vi:0 tag:CSIMUX_FRAME channel:0x00 frame:1 vi_tstamp:129925171392 data:0x00000000000000a0
rtcpu_vinotify_event: tstamp:4060166846 cch:0 vi:0 tag:CHANSEL_PXL_EOF channel:0x23 frame:1 vi_tstamp:129923836800 data:0x0000000004370002
rtcpu_vinotify_event: tstamp:4060167015 cch:0 vi:0 tag:ATOMP_FRAME_DONE channel:0x23 frame:1 vi_tstamp:129923837312 data:0x0000000000000000
16

Thanks for Sharing
Would like to inquire synchronously. Could you please tell me if our non-i2c solution can actually work in principle?
I have seen similar non-i2c solutions on the forum, but I haven’t found the final conclusion.

17

hello 1191208688,

it’s supported as long as the frame has detected by VI engine correctly.
I did seen some topics bring-up MIPI stream (through SerDes chip) without i2c communication.

18

OK. Thank you for your reply.
I currently have some doubts about the filling of the pix_clk_hz parameter.
Our current image format is 1600*1300 @ 30 yuv uyvy 16 bits.
The official configuration is 1600 * 1300 * 30 = 62,400,000
When I set the value to 90M, the err_data was 131072.
When I set the value to 100M, the err_data was 512.
It seems that 512 is an incorrect data packet size. Has my plk been adjusted to the normal value yet? All I need to do now is to adjust the image size to try.

19

Here is the current vi debug log. Could you please take a look and see if you can identify any issues? Based on the analysis you mentioned earlier, it seems that we are currently not receiving the “end of file” signal. It appears that the error is caused by not receiving the standard for frame termination?
vi.log.txt (110.9 KB)

20

From the current log, it can be seen that these two CORRECTABLE_ERR messages have been printed continuously. The first error is related to the switch flow and the timing of the output flow. The second error is not well understood. Could it be caused by a hardware issue?

     kworker/2:3-172     [002] .......   299.504512: rtcpu_nvcsi_intr: tstamp:10172455172 class:GLOBAL type:STREAM_VC phy:0 cil:0 st:0 vc:0 status:0x0000000c
     kworker/2:3-172     [002] .......   299.504512: rtcpu_nvcsi_intr: tstamp:10172455172 class:CORRECTABLE_ERR type:STREAM_VC phy:0 cil:0 st:0 vc:0 status:0x0000000c
     kworker/2:3-172     [002] .......   299.504513: rtcpu_nvcsi_intr: tstamp:10172455172 class:CORRECTABLE_ERR type:PHY_INTR phy:0 cil:0 st:0 vc:0 status:0x00000110
     kworker/2:3-172     [002] .......   299.504513: rtcpu_nvcsi_intr: tstamp:10172463244 class:GLOBAL type:STREAM_VC phy:0 cil:0 st:0 vc:0 status:0x00000004
     kworker/2:3-172     [002] .......   299.504514: rtcpu_nvcsi_intr: tstamp:10172463244 class:CORRECTABLE_ERR type:STREAM_VC phy:0 cil:0 st:0 vc:0 status:0x00000004
     kworker/2:3-172     [002] .......   299.504514: rtcpu_nvcsi_intr: tstamp:10172463244 class:CORRECTABLE_ERR type:PHY_INTR phy:0 cil:0 st:0 vc:0 status:0x00000110
     kworker/2:3-172     [002] .......   299.504514: rtcpu_vinotify_error: tstamp:10172464893 cch:0 vi:0 tag:CSIMUX_FRAME channel:0x00 frame:0 vi_tstamp:325518463104 data:0x00000000000000a0
     kworker/2:3-172     [002] .......   299.504515: rtcpu_nvcsi_intr: tstamp:10172467080 class:GLOBAL type:STREAM_VC phy:0 cil:0 st:0 vc:0 status:0x00000004
     kworker/2:3-172     [002] .......   299.504515: rtcpu_nvcsi_intr: tstamp:10172467080 class:CORRECTABLE_ERR type:STREAM_VC phy:0 cil:0 st:0 vc:0 status:0x00000004
     kworker/2:3-172     [002] .......   299.504516: rtcpu_nvcsi_intr: tstamp:10172467080 class:CORRECTABLE_ERR type:PHY_INTR phy:0 cil:0 st:0 vc:0 status:0x00000110
     kworker/2:3-172     [002] .......   299.504516: rtcpu_nvcsi_intr: tstamp:10172473287 class:GLOBAL type:STREAM_VC phy:0 cil:0 st:0 vc:0 status:0x00000004
     kworker/2:3-172     [002] .......   299.504516: rtcpu_nvcsi_intr: tstamp:10172473287 class:CORRECTABLE_ERR type:STREAM_VC phy:0 cil:0 st:0 vc:0 status:0x00000004
     kworker/2:3-172     [002] .......   299.504517: rtcpu_nvcsi_intr: tstamp:10172473287 class:CORRECTABLE_ERR type:PHY_INTR phy:0 cil:0 st:0 vc:0 status:0x00000110
     kworker/2:3-172     [002] .......   299.504517: rtcpu_nvcsi_intr: tstamp:10172480732 class:GLOBAL type:STREAM_VC phy:0 cil:0 st:0 vc:0 status:0x00000004
     kworker/2:3-172     [002] .......   299.504518: rtcpu_nvcsi_intr: tstamp:10172480732 class:CORRECTABLE_ERR type:STREAM_VC phy:0 cil:0 st:0 vc:0 status:0x00000004
     kworker/2:3-172     [002] .......   299.504518: rtcpu_nvcsi_intr: tstamp:10172480732 class:CORRECTABLE_ERR type:PHY_INTR phy:0 cil:0 st:0 vc:0 status:0x00000110
     kworker/2:3-172     [002] .......   299.504518: rtcpu_nvcsi_intr: tstamp:10172483838 class:GLOBAL type:STREAM_VC phy:0 cil:0 st:0 vc:0 status:0x00000004
     kworker/2:3-172     [002] .......   299.504519: rtcpu_nvcsi_intr: tstamp:10172483838 class:CORRECTABLE_ERR type:STREAM_VC phy:0 cil:0 st:0 vc:0 status:0x00000004
     kworker/2:3-172     [002] .......   299.504519: rtcpu_nvcsi_intr: tstamp:10172483838 class:CORRECTABLE_ERR type:PHY_INTR phy:0 cil:0 st:0 vc:0 status:0x00000110
     kworker/2:3-172     [002] .......   299.504520: rtcpu_nvcsi_intr: tstamp:10172487557 class:GLOBAL type:STREAM_VC phy:0 cil:0 st:0 vc:0 status:0x00000004
     kworker/2:3-172     [002] .......   299.504520: rtcpu_nvcsi_intr: tstamp:10172487557 class:CORRECTABLE_ERR type:STREAM_VC phy:0 cil:0 st:0 vc:0 status:0x00000004
     kworker/2:3-172     [002] .......   299.504520: rtcpu_nvcsi_intr: tstamp:10172487557 class:CORRECTABLE_ERR type:PHY_INTR phy:0 cil:0 st:0 vc:0 status:0x00000110
     kworker/2:3-172     [002] .......   299.504521: rtcpu_nvcsi_intr: tstamp:10172494389 class:GLOBAL type:STREAM_VC phy:0 cil:0 st:0 vc:0 status:0x00000004
     kworker/2:3-172     [002] .......   299.504521: rtcpu_nvcsi_intr: tstamp:10172494389 class:CORRECTABLE_ERR type:STREAM_VC phy:0 cil:0 st:0 vc:0 status:0x00000004
     kworker/2:3-172     [002] .......   299.504521: rtcpu_nvcsi_intr: tstamp:10172494389 class:CORRECTABLE_ERR type:PHY_INTR phy:0 cil:0 st:0 vc:0 status:0x00000110
     kworker/2:3-172     [002] .......   299.504522: rtcpu_vinotify_event: tstamp:10172504167 cch:0 vi:0 tag:CSIMUX_FRAME channel:0x00 frame:0 vi_tstamp:325518463104 data:0x00000000000000a0
     kworker/2:3-172     [002] .......   299.504522: rtcpu_vinotify_event: tstamp:10172507180 cch:0 vi:0 tag:CHANSEL_SHORT_FRAME channel:0x01 frame:0 vi_tstamp:325518463104 data:0x00a4200001000000
     kworker/2:3-172     [002] .......   299.504523: rtcpu_vinotify_event: tstamp:10172507313 cch:0 vi:0 tag:FS channel:0x00 frame:0 vi_tstamp:325518463104 data:0x0000000000000010
     kworker/2:3-172     [002] .......   299.504523: rtcpu_vinotify_event: tstamp:10172507473 cch:0 vi:0 tag:ATOMP_FE channel:0x00 frame:0 vi_tstamp:325518463200 data:0x0000000800000000
     kworker/2:3-172     [002] .......   299.504524: rtcpu_vinotify_event: tstamp:10172507609 cch:0 vi:0 tag:VIFALC_ACTIONLST channel:0x23 frame:0 vi_tstamp:325518587808 data:0x0000000007020050
     kworker/2:3-172     [002] .......   299.504524: rtcpu_vinotify_event: tstamp:10172507765 cch:0 vi:0 tag:ATOMP_FS channel:0x00 frame:0 vi_tstamp:325518463200 data:0x0000000800000000
     kworker/2:3-172     [002] .......   299.504524: rtcpu_vinotify_event: tstamp:10172507901 cch:0 vi:0 tag:CHANSEL_PXL_SOF channel:0x23 frame:0 vi_tstamp:325518481920 data:0x0000000000000001
     kworker/2:3-172     [002] .......   299.504525: rtcpu_vinotify_event: tstamp:10172508055 cch:0 vi:0 tag:VIFALC_ACTIONLST channel:0x23 frame:0 vi_tstamp:325518660320 data:0x0000000008020050
     kworker/2:3-172     [002] .......   299.504525: rtcpu_vinotify_event: tstamp:10172508187 cch:0 vi:0 tag:CHANSEL_FAULT channel:0x23 frame:0 vi_tstamp:325518491296 data:0x0000000000000200
     kworker/2:3-172     [002] .......   299.504526: rtcpu_vinotify_event: tstamp:10172508338 cch:0 vi:0 tag:VIFALC_ACTIONLST channel:0x23 frame:0 vi_tstamp:325518750368 data:0x0000000001020050
     kworker/2:3-172     [002] .......   299.504526: rtcpu_vinotify_event: tstamp:10172508471 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:325518979648 data:0x359d580010000000
     kworker/2:3-172     [002] .......   299.504526: rtcpu_vinotify_event: tstamp:10172508620 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:325519037408 data:0x0000000031000051
     kworker/2:3-172     [002] .......   299.504527: rtcpu_vinotify_error: tstamp:10172558318 cch:-1 vi:0 tag:CSIMUX_FRAME channel:0x00 frame:0 vi_tstamp:325521655296 data:0x0000000000000120
     kworker/2:3-172     [002] .......   299.504527: rtcpu_vinotify_event: tstamp:10172559255 cch:-1 vi:0 tag:CSIMUX_FRAME channel:0x00 frame:0 vi_tstamp:325521655296 data:0x0000000000000120
     kworker/2:3-172     [002] .......   299.560221: rtcpu_vinotify_event: tstamp:10173046830 cch:-1 vi:0 tag:CHANSEL_SHORT_FRAME channel:0x01 frame:0 vi_tstamp:325521655328 data:0x0009200001000000
     kworker/2:3-172     [002] .......   299.560228: rtcpu_vinotify_event: tstamp:10173047050 cch:-1 vi:0 tag:ATOMP_FE channel:0x00 frame:0 vi_tstamp:325521655392 data:0x0000000800000000
     kworker/2:3-172     [002] .......   304.832205: rtcpu_string: tstamp:10337952002 id:0x04010000 str:"VM0 deactivating."
type or paste code here
21

hello 1191208688,

although there’s CHANSEL_PXL_SOF, but it doesn’t shows CHANSEL_PXL_EOF to indicate end-of-frame. so.. you’ve seen CHANSEL_FAULT reported for each capture frame.
per your logs,
CHANSEL_FAULT channel:0x23 frame:0 vi_tstamp:2989487363968 data:0x0000000000000200
the error code, 0x200 it means a line ends with fewer pixels than expected. (but, it’s not reporting how many is expected).

is your sensor output embedded metadata line?
please see-also Property-Value Pairs for the configuration of embedded_metadata_height.

22

No metadata has been configured.