vi2 channel error while streaming MT9M021

Robotics & Edge Computing Jetson & Embedded Systems Jetson TX1
21

I tried reading the register using devmem2 and by adding debug code in driver:
Using devmem2(multiple readouts during streaming):

ubuntu@tegra-ubuntu:~/debug/devmem2$ sudo ./devmem2 0x54080940
/dev/mem opened.
Memory mapped at address 0x7fa7422000.
Value at address 0x1409812800 (0x7fa7422940): 0x322122678304
ubuntu@tegra-ubuntu:~/debug/devmem2$ sudo ./devmem2 0x54080940
/dev/mem opened.
Memory mapped at address 0x7fada26000.
Value at address 0x1409812800 (0x7fada26940): 0x322122940512
ubuntu@tegra-ubuntu:~/debug/devmem2$ sudo ./devmem2 0x54080940
/dev/mem opened.
Memory mapped at address 0x7fa0fb9000.
Value at address 0x1409812800 (0x7fa0fb9940): 0x322122547200

Using debug code:

[  127.712325] mt9m021 6-0010: Starting stream
[  127.712412] mt9m021 6-0010: mt9m021_write: 0x10dc to 0x301a
[  127.732846] vi vi: CSI DEBUG tegra_csi_error
[  127.737120] vi vi: CSI DEBUG csi2_error
[  127.741141] vi vi: csi2_read:port 0 offset 0x000000d0
[  127.746193] vi vi: TEGRA_CSI_PHY_CIL_COMMAND 0x00000001
[  127.751534] vi vi: TEGRA_CSI_PIXEL_PARSER_STATUS 0x00000000
[  127.757112] vi vi: TEGRA_CSI_CIL_STATUS 0x00000002
[  127.761959] vi vi: TEGRA_CSI_CILX_STATUS 0x00020020
[  127.766839] vi vi: vi2_channel_error_status:error 20022 frame 0
[  127.772790] vi vi: CSI DEBUG tegra_csi_pad_control
[  127.782910] vi vi: CSI DEBUG tegra_csi_error
[  127.787180] vi vi: CSI DEBUG csi2_error
[  127.791152] vi vi: csi2_read:port 0 offset 0x000000d0
[  127.796268] vi vi: TEGRA_CSI_PHY_CIL_COMMAND 0x00000001
[  127.801594] vi vi: TEGRA_CSI_PIXEL_PARSER_STATUS 0x00000100
[  127.807191] vi vi: TEGRA_CSI_CIL_STATUS 0x00000002
[  127.812149] vi vi: TEGRA_CSI_CILX_STATUS 0x00020020
[  127.817046] vi vi: vi2_channel_error_status:error 20022 frame 1
[  127.823283] vi vi: CSI DEBUG tegra_csi_pad_control
[  128.028705] video4linux video0: frame start syncpt timeout!0
[  128.034536] vi vi: CSI DEBUG tegra_csi_pad_control
[  128.041862] vi vi: CSI DEBUG tegra_csi_status
[  128.046355] vi vi: CSI DEBUG csi2_status
[  128.052110] vi vi: TEGRA_CSI_PIXEL_PARSER_STATUS 0x00000000
[  128.057817] vi vi: TEGRA_CSI_CIL_STATUS 0x00000002
[  128.062746] vi vi: TEGRA_CSI_CILX_STATUS 0x00020020
[  128.067625] vi vi: TEGRA_CSI_DEBUG_COUNTER_0 0x000010ee
[  128.072994] vi vi: TEGRA_CSI_DEBUG_COUNTER_1 0x00000004
[  128.078349] vi vi: TEGRA_CSI_DEBUG_COUNTER_2 0x000053f5
[  128.083592] vi vi: CSI DEBUG tegra_csi_error_recover
[  128.088784] vi vi: CSI DEBUG csi2_error_recover
[  128.093361] vi vi: CSI DEBUG tegra_csi_stop_streaming
[  128.098508] vi vi: CSI DEBUG csi2_stop_streaming
[  128.103123] vi vi: CSI DEBUG tegra_csi_start_streaming
[  128.108358] vi vi: CSI DEBUG csi2_start_streaming
[  128.113065] vi vi: csi2_read:port 0 offset 0x000000d0
[  128.118291] vi vi: CSI DEBUG tegra_csi_pad_control
[  128.149036] vi vi: CSI DEBUG tegra_csi_error
[  128.153422] vi vi: CSI DEBUG csi2_error
[  128.157360] vi vi: csi2_read:port 0 offset 0x000000d0
[  128.162575] vi vi: TEGRA_CSI_PHY_CIL_COMMAND 0x00000001
[  128.167803] vi vi: TEGRA_CSI_PIXEL_PARSER_STATUS 0x00000100
[  128.174917] vi vi: TEGRA_CSI_CIL_STATUS 0x00000012
[  128.179738] vi vi: TEGRA_CSI_CILX_STATUS 0x00060060
[  128.184612] vi vi: vi2_channel_error_status:error 20022 frame 3
22

hello EV,

after checking the register value, you always got bit-18 pull high, which means your had mipi signal error.
please refer to the details as below,

CILA_DATA_LANE1_CTRL_ERR: Control Error. Set when CIL-A detects LP state 01 or 10 followed by a
stop state (LP11) instead of transitioning

i think you should co-working with your hardware engineer to check your mipi signal is following the mipi spec.
thanks

23

Hi Jerry,

I am confused. I understand that the bit 18 of the devmem2 output is set. But, why isn’t this error present in the debug prints?

TEGRA_CSI_CILX_STATUS 0x00020020

Am I reading the right register using devmem2? The values printed from code and using devmem2 doesn’t make sense. Are they both the same register?

24

We tried to look into the possible hardware issues, but couldn’t find any. We are stuck at the same stage as earlier.
Jerry, how can I ensure that it’s not an external register read error, since the values printed out from inside the code doesn’t show any LP state transition errors.
Here are some captures we obtained from hardware while attempting streaming.
1280x960_MIPI_data_Hsync_Rise:

800×600 11.9 KB

MIPI Clock rate:

800×600 11.4 KB

Horizontal rate:

800×600 13.1 KB

Vertical rate:

800×600 12.2 KB

Let me know if you have any suggestions for the debug. We are trying to fix this issue asap so that we can proceed further.

25

hello EV,

could you help measure the signal as below?
External Media

D_P and D_N should following above.
you could configure the HS0 by settings the THS_SETTEL, and also try to configure as discontinuous mode.
thanks

26

Hi Jerry,

I used an alternate version of devmem2 from http://free-electrons.com/pub/mirror/devmem2.c and tried to perform the memory read again. In the meanwhile when the hardware team obtain the capture, I would like to get your help to check if the issues are valid:

ubuntu@tegra-ubuntu:~$ sudo devmem2 0x54080908
/dev/mem opened.
Memory mapped at address 0x7f994d3000.
Value at address 0x54080908 (0x7f994d3908): 0x1

ubuntu@tegra-ubuntu:~$ sudo devmem2 0x54081140
/dev/mem opened.
Memory mapped at address 0x7f952ed000.
Value at address 0x54081140 (0x7f952ed140): 0x0

ubuntu@tegra-ubuntu:~$ sudo devmem2 0x54080940
/dev/mem opened.
Memory mapped at address 0x7fb548a000.
Value at address 0x54080940 (0x7fb548a940): 0x20020

From what I understand, it signals Start of Transmission Multi Bit error on both Lane 0 and Lane 1.
Can the LP state transition error still a valid? What would be the best way to take this debug forward?
Let me know your suggestions.
Thanks!

27

hello EV,

theoretically, sensor generated signal should following the MIPI specification.
there are only several configurations at Tegra side.
in our experience, the most related configuration would be settle time and discontinuous mode, please have a try.

moreover, since VI mode did not included all the sensor device tree settings.
if you’re using the v4l2-ctl to verify the driver, you should confirm the your sensor settings at below path
please also refer to TRM and check the 35.6.278 NVCSI_PHY_0_NVCSI_CIL_A_CONTROL_0 for more details. thanks

/kernel/kernel-4.4/drivers/media/platform/tegra/camera/csi/csi4_registers.h
28

Hi Jerry,

Thank for the response.
Are you referring to Tegra X1 (SoC) Technical Reference Manual?
I couldn’t find information about the above-mentioned register in it.
Also can you please let me know where to find “/kernel/kernel-4.4/”. I tried looking up the file but couldn’t find it.
In TX1:

ubuntu@tegra-ubuntu:/usr/src/linux-headers-3.10.96-tegra/drivers/media/platform/tegra/camera$ ls
Makefile

In my driver development path:

ev@ev:kernel_source$ cd drivers/media/platform/tegra/camera/
ev@ev:camera$ ls
built-in.mod.c   camera_common.o  core.c  graph.c   mc_common.c  modules.builtin  vi2_fops.c
built-in.o       channel.c        core.h  graph.o   mc_common.h  modules.order    vi2_fops.h
camera_common.c  channel.o        core.o  Makefile  mc_common.o  registers.h      vi2_fops.o
29

hello EV,

may i know are you still working on R24.2.1?
please search CSI_PHY_CILA_CONTROL0 in the Tegra X1 (SoC) Technical Reference Manual

also, shown the VI driver code path as below for R24.2.1

kernel/drivers/media/platform/tegra/camera

since we transit the kernel version to kernel-4.4 on R28.1, the VI driver code path is

kernel/kernel-4.4/drivers/media/platform/tegra/camera/vi
30

Hi Jerry,

Yes, we are still using R24.2.1.
As suggested by you, I changed the value of THS_SETTLE. I changed the default value from 0xA to 0xB in drivers/media/platform/tegra/csi/csi2_fops.c and this fixed the channel error issue.
Right now from the dmesg I observe that we have the following error.

[  172.198394] video4linux video0: frame start syncpt timeout!0

What could cause this issue? Do you have any suggestion for additional debug code which could help fix this issue fast. I observe that the captures obtained using yavta is blank.

Regards
EV

31

hello EV,

according to my comment #27, you can try to modify the register (BYPASS_LP_SEQ) settings as discontinuous/continuous mode.
also, you should measure the MIPI signal timing about T_HS_ZERO, we should configure correct value in driver side.

32

Hi Jerry,

Is the BYPASS_LP_SEQ bit supposed to be set to ‘0’ when we are operating in discontinuous mode?
We are taking hardware capture. Once it is available, I will set the T_HS_ZERO value according to that.

Thanks
EV

33

Thank you for the support! I could fix the issue.
Fix:

  1. Changed to the discontinuous mode by setting BYPASS_LP_SEQ.
  2. Changed the T_HS_ZERO bit to 0x9 instead of 0xA based on the captures we obtained.

Using the following commands, I am not able to capture frames:

v4l2-ctl -d /dev/video0 --verbose --set-fmt-video=width=1280,height=720,pixelformat=RG12 --set-ctrl bypass_mode=0 --stream-mmap --stream-count=1 --stream-to=data.raw

./yavta /dev/video0 -c1 -n1 -s1280x720 -fSRGGB12 -Fdata8.raw

Attempted gstreamer and nvgstcapture but didn’t work. I will open another thread to debug those.