DS90UB954-Q1EVM: No MIPI CSI output when connected to camera with DS90UB913A

Hello,

Thank you for your question. The output functions as expected when sending the video data from the 954 patgen but not from the camera attached to the 913, is that correct? Are you able to communicate with the 913 and camera successfully? Was this register dump during operation or was the 954 not connected to the 913? Based on register 0x4D, the 954 does not have lock and registers 0x4E, 0x4F, and 0x50 indicate there is no serializer connection. Also register 0x20 is currently set to 0x30, which disabled forwarding of the RX ports, to forward data from the RX port to the TX output port set register 0x20 = 0x0. It is also recommended to set registers 0x41 = 0xA9.

Hi Darrah,

Thank you for the help. We got output from data lines after adjusting some registers. However, the MIPI clock lines had no wave form as well as no voltage. The serializer still is recognized as UB953 instead of UB913A. Please see new register dump linked below. Thank you.

www.dropbox.com/.../ub913a6.7.24.nrd

Hello,

Can you attach the register dump as a file attachment? Are you connecting the 954 to a display or SoC to receive the data, or are you only probing the pins for a signal? Do you have functional communication between the serializer and the camera? 

Hi Darrah,

ub913a6.7.24.zipPlease see attached. The connection between ser and deser looks fine, same as pic send last time, except that I used port 0 this time so that the status can also be seen from register values. I just probed pins for signal using a digital oscilloscope.

The registers show that the devices have lock and pass and that there is CSI data received (registers  0x73 - 0x76). So from the register dump, data should be seen on the output. Which pins specifically are you probing that are not showing a signal? The line length unstable and line length changed flags are set in register 0x4E, so it is possible that there could be an issue with the data being output by the camera.

CSI_CLK0P/N two pins have no waveform and voltage. data lanes (CSI_D0P/N: CSI_D3P/N) all have signals. When I enabled pattern generator, it seems to be the same. Therefore, I am thinking if I missed any setting or if it's hardware issue with the eval board.

The pattern generator does not have separate configurations for the clock and data lanes. Once the pattern generator is enabled it will output all the signals necessary to generate a pattern that matches the specifications programmed via the registers. If the clock pins have no waveforms for both the pattern generator and camera then it may be a hardware issue with the traces coming from the pins. Are you able to probe the pins of the camera to verify that the clock signal is being sent to the serializer?

Please see below pictures of waveforms of PCLK, HSYNC, VSYNC on UB913A side. I also tried predefined scripts from ALP for pattern generator. All of them has signals for data lanes but not for clock lanes. Is it safe to say that the eval board needs replacement? Thank you.

Are you probing the CSI_CLK0N and CSI_CLK0P pins directly or are you probing the connector? Do you have a display or CSI analyzer that the 954 EVM could be connected to to verify that the output is not being output properly? While it is unlikely that no signal on the clocks will result in an image, having a second method in addition to probing would help verify that the clock signals are incorrect and there is a hardware issue.

I probed on the resistors next to the UB954. Tried both before and after the resistor. So it's safe to say there is no clock output from the deser. We don't have any display or CSI analyzer on hand that can verify the output otherwise. Please advise. Thank you.

You mean the R33 and R34 resistors, not R42 or R43? Is the signal high without any toggling or is the signal low? Without a display or analyzer it is difficult to evaluate the data that is being output by the device as valid or not. Besides the line length unstable and line length change flags in register 0x4E, there are no errors being reported by the 954. These errors indicate that the received data frames have errors but are not related to the clock or data output pins directly and would be more likely due to the camera configuration or connection. 

Yes. R33 and R34. The voltage of the two is close to 0 without much changes. I don't think it's the camera's problem, for, if it's the case, pattern output should be normal.

If we are going to get an analyzer, do you have any recommended models? Preferably, it should be able to analyze both CSI and DSI signals, and can tell details of the image signal like hsync, hfp, hbp, vbp,vfp, vsync, etc. Or, are the information already available in UB954 register values?

Another quick question. DS90UB638-Q1 and TDES954 have the same pinouts. Are they not compatible with the UB913A?

There aren't any specific analyzer recommendations. However, the 954 does have the ability to output the HSYNC and VSYNC signals onto GPIO pins (section 7.4.14 of the datasheet). While the DS90UB638 and TDES954 have the same pinout they are not compatible with the 913A. The DS90UB954, DS90UB638, and TDES954 are all from different portfolios that are not interoperable. 

I was advised by customer service that I need to get confirmation from you in order to get a replacement. What else should I do to get the confirmation? It's not practical for us to get a several-thousand dollar analyzer to diagnose the board. Any other way to confirm that? Will a video of probing different pins of MIPI output do? Thank you.

Before assuming that there is an issue with the board, we can walk through the entire systems hardware setup and registers to verify that everything is configured properly, but it is still possible that the clock actually is behaving as expected. The clock can be in a low power mode, and given that the partner 913 is operating with a much lower bandwidth than the 954 is outputting, there will be periods where the 954 is not outputting data packets due to the difference in speeds, resulting in an idle bus.

Additionally, per the MIPI CSI specification, the CSI clock during data transmission is on a scale of mV. Based on the provided register configurations continuous clock is being used, which means no clock transitions would be seen between the transmission of each data packet, so a low mV signal is expected on the pins at all times. When you are probing the clock signal, are you setting the oscilloscope scale this small? Is a high bandwidth oscilloscope being used? Since the clock signal is a high frequency signal, the oscilloscope may be attenuating the signal, the termination can also impact what is being seen.

What you are talking about is the uncertainty of input from UB913. However, I have mentioned that I have tried pattern generator, and also tried loading predefined script files came with the ALP. AFAIK, if I power up the board and then load the script files and then take the measurements, then you can replicate the results following the same steps. Attached are the script files I tried and pic of the oscilloscope I used. Never had issue with bandwidth. All the script files gave signal on data lanes but none on clock lanes. Attached is also the pic of the board showing all the jumpers. I hope that's enough for you to test under the exact same conditions and see if there are waveforms on the MIPI clock lanes on your end. Thank you.

954_CSI_patgen_PreDefScripts.zip

The CSI protocol uses different voltages and signaling on the clock and data lanes. While the data lanes see transitions between states and higher voltages, the clock lane will not see any transitions and will be at a lower mV level voltage. The clock lane signal here has a frequency of 400MHz. Due to these differences the particular measurement methods can display the data lanes but not the clock lanes.

From the picture, your oscilloscope is a 100MHz scope, which does not have sufficient bandwidth to measure a 400MHz or greater signal. The signal will be greatly attenuated. In order to capture CSI clock signals without attenuation a high bandwidth oscilloscope is necessary.

If you adjust the vertical scale on the oscilloscope to the mV range, you may be able to see the voltage fluctuating, but note the signal will still be greatly attenuated which will impact the amplitude. Can you try to measure the clock using a smaller scale than the data lanes, and share shots of all the lanes?