DS90UB960-Q1 no signal output

Question

DS90UB960-Q1 no signal output

Opened this issue 2 years ago · 7 comments

We use the NVIDIA Jetson SerDes sensor interface card. The four registers CSI_PORT_SEL, FWD_CTL1, CSI_PLL_CTL and CSI_CTL are now configured, the ub960 is set as the pattern generation mode, which means that the ub960 will generate video test patterns for the CSI-2 transmitter outputs. However, the CSI signal could not be probed with an oscilloscope on the pin of the ub960, nor could data be read using the v4l2 interface on the Orin.

Could you tell me what the problem is?

Answer 1 · 2023-04-17T12:39:41.000Z

Hello,

I'm sorry, but we don't officially support using the test pattern generator on the UB960. If you are having trouble configuring that part in particular, TI would probably be able to provide better support. I would refer you to the datasheet, but you appear to have already referenced it 🙂

Something to keep in mind is that you will need to configure the Jetson for the exact video settings the pattern generator is outputting, otherwise capture will fail with v4l2-ctl. You should reference one of our sample drivers (such as the OV10640 to see which properties we set in the device tree. You may also want to reference NVIDIA's documentation regarding sensor driver development.

If you already have one of the supported camera modules, I would suggest skipping the test pattern step. You will be able to stream out of the box without changing any code.

I hope that was helpful. Please let me know if you have additional questions.

Thanks.
Cody

Answer 2 · 2023-04-18T12:06:53.000Z

Hi Cody,

Thank you for your reply!

Now, the oscilloscope has detected a signal on the UB960 output pin of NVIDIA Jetson SerDes sensor interface card, both the data signal and the clock signal are correct.

But it times out when reading data with v4l2-ctl, log is "uncorr_err: request timed out after 2500 ms". The vi module starts to recover. Call vi_capture_release first to release the resources, so the subsequent stop streaming and start streaming both fail, and the data is still not read, and the vi module starts to recover again.

How can I debug this bug?

Answer 3 · 2023-04-20T12:02:20.000Z

Excellent! What did you have to change to view the signals on your oscilloscope?

First I would check to make sure your device tree settings match the output of your test pattern generator. If they do, you might be able to figure out what the problem is by enabling the CSI trace logs to see if FS, FE, or pixel data packets are making it through. We provide an example script called trace-enable that will turn on the logs, which can be accessed by viewing /sys/kernel/debug/tracing/trace. Just keep in mind that these logs require a lot of CPU time so it's best not to leave it enabled long-term.

Good luck!

Answer 4 · 2023-04-20T12:26:17.000Z

Change the mode of the clock from continuous to non-continuous.
After I enable trace-enable, the dump logs are as follows, how should I understand them?

kworker/4:2-144 [004] .... 79.551462: rtcpu_vinotify_event: tstamp:3600080185 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:115187208608 data:0x379d580010000000
kworker/4:2-144 [004] .... 79.551462: rtcpu_vinotify_event: tstamp:3600080338 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:115187215104 data:0x0000000031000001
kworker/4:2-144 [004] .... 79.551462: rtcpu_vinotify_event: tstamp:3600080491 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:115187271264 data:0x379d550010000000
kworker/4:2-144 [004] .... 79.551463: rtcpu_vinotify_event: tstamp:3600080622 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:115187277888 data:0x0000000031000002
kworker/4:2-144 [004] .... 79.551464: rtcpu_nvcsi_intr: tstamp:3600244871 class:GLOBAL type:PHY_INTR0 phy:0 cil:0 st:0 vc:0 status:0x00000044
kworker/4:2-144 [004] .... 79.551465: rtcpu_nvcsi_intr: tstamp:3600244871 class:GLOBAL type:PHY_INTR0 phy:0 cil:1 st:0 vc:0 status:0x00000044
kworker/4:2-144 [004] .... 79.551465: rtcpu_nvcsi_intr: tstamp:3600245819 class:GLOBAL type:PHY_INTR0 phy:0 cil:0 st:0 vc:0 status:0x00000044
kworker/4:2-144 [004] .... 79.551465: rtcpu_nvcsi_intr: tstamp:3600245819 class:GLOBAL type:PHY_INTR0 phy:0 cil:1 st:0 vc:0 status:0x00000044
kworker/4:2-144 [004] .... 79.551466: rtcpu_nvcsi_intr: tstamp:3600246810 class:GLOBAL type:PHY_INTR0 phy:0 cil:0 st:0 vc:0 status:0x00000044
kworker/4:2-144 [004] .... 79.551466: rtcpu_nvcsi_intr: tstamp:3600246810 class:GLOBAL type:PHY_INTR0 phy:0 cil:1 st:0 vc:0 status:0x00000044
kworker/4:2-144 [004] .... 79.551467: rtcpu_nvcsi_intr: tstamp:3600247803 class:GLOBAL type:PHY_INTR0 phy:0 cil:0 st:0 vc:0 status:0x00000044
kworker/4:2-144 [004] .... 79.551467: rtcpu_nvcsi_intr: tstamp:3600247803 class:GLOBAL type:PHY_INTR0 phy:0 cil:1 st:0 vc:0 status:0x00000044
kworker/4:2-144 [004] .... 79.551468: rtcpu_nvcsi_intr: tstamp:3600248803 class:GLOBAL type:PHY_INTR0 phy:0 cil:0 st:0 vc:0 status:0x00000044
kworker/4:2-144 [004] .... 79.551468: rtcpu_nvcsi_intr: tstamp:3600248803 class:GLOBAL type:PHY_INTR0 phy:0 cil:1 st:0 vc:0 status:0x00000044
kworker/4:2-144 [004] .... 79.551468: rtcpu_nvcsi_intr: tstamp:3600249726 class:GLOBAL type:PHY_INTR0 phy:0 cil:0 st:0 vc:0 status:0x00000088
kworker/4:2-144 [004] .... 79.551469: rtcpu_nvcsi_intr: tstamp:3600249726 class:GLOBAL type:PHY_INTR0 phy:0 cil:1 st:0 vc:0 status:0x0000008

Answer 5 · 2023-04-21T19:05:51.000Z

You can put those messages through NVIDIA's capture status decoder like this:

nvidia@anaheim:~$ nvcapture-status-decoder kworker/4:2-144 [004] .... 79.551464: rtcpu_nvcsi_intr: tstamp:3600244871 class:GLOBAL type:PHY_INTR0 phy:0 cil:0 st:0 vc:0 status:0x00000044
NVIDIA camera capture status decoder utility (Version 2.00)
Copyright (C) 2019-2020, NVIDIA Corporation. All rights reserved.

Class: Global
Type: PHY_Interrupt0
PHY: 0
CIL: 0
Stream: 0
VC: 0
Status: 68
Timestamp: 3600244871

PHY_Interrupt0 : 0x0000000000000044
    -cil_data_lane_sot_mb_err0    [ 2]: 1
        More than one bit error detected on the data lane [A/B]0 sync word

    -cil_data_lane_sot_mb_err1    [ 6]: 1
        More than one bit error detected on the data lane [A/B]1 sync word

Not all of the messages are helpful, but you should see FS, FE, ATOMP messages when it's working correctly. The NVIDIA forums have some more information about these logs, but even so they are still rather cryptic.

Thanks,
Cody

Answer 6 · 2023-05-20T05:41:21.000Z

If I want to test the clock and signal output by UB960 with an oscilloscope, where is the measurement accurate?
Now I measure the clock and data signals directly on the pins of UB960, and the HS voltage of the data signal is high, reaching 500mv. The UB953 has a data rate of 400Mbps and a clock of 200Mhz. Whether I set the data rate of UB960 to 400Mbps or 800Mbps (the sensor's serdes_pix_clk_hz is set to 200000000 and 400000000), the log of LP sequence error will appear, so v4l2-ctl reads data timeout. Does the jetson side read phy_mode, num_lanes, cil_settletime and serdes_pix_clk_hz in the sensor device tree to configure its own csi? I have these two kinds of errors, which registers and configurations should I adjust?

Answer 7 · 2023-05-24T15:40:13.000Z

Hello,

I'd start with probing on the pins themselves. There aren't any more convenient test points broken out on those lanes.

Yes, the Jetson reads the properties for configuring its own CSI input from those properties you listed. All of the Jetson CSI configuration is performed via the device tree. I would recommend verifying that the UB960 is receiving valid frames using one of its GPIOs before diving into the Jetson CSI configuration. If you're following our camera modules as an example for your driver, you may not need to change anything about the UB960's CSI configuration. Though I can't say for sure without knowing more about your application.

Thanks,
Cody