• State TI Thinks Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 2 answers
  • Subscribers 33 subscribers
  • Views 4800 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Linux/SN65DSI83: generates test pattern OK, but fails to streaming MIPI DSI data

nestor lee
Intellectual 985 points
Part Number: SN65DSI83

Tool/software: Linux

Hi TI Experts,

We are debugging a Android PAD project for our customer.

This project is an variation from former design. In previous design, the CPU is Qualcomm MSM8939, and the LCD display uses a MIPI DSI interface, everything works fine.

The new design changed the LCD display interface into LVDS(Flat-link) . So the connection is MSM8939 -> SN65DSI83 -> LVDS LCD display. And the SN65DSI83 uses MIPI D-PHY clock as the clock source.

We've made great efforts to make the LCD display to work. We've been testing the hardware by using the test pattern feature of SN65DSI83, finally by changing the D-PHY clock to continuous mode, we succeeded. The test pattern  from SN65DSI83 is as follows:

By seeing the test pattern, we believe that the clock is OK(we uses an oscilloscope to show the clocks from D-PHY and LVDS, both to be correct), the parameters of the LCD display is matched. however, we still cannot see any outputs in the LCD by switch the test pattern  feature off. The timing parameter of the MIPI DSI has been reviewed, and seems to be good.

The LCD resolution is 1280x800, the MIPI D-PHY clock is 200MHz, and  in our settings, we divided it by 4 as the LVDS clock.  

The SN65DSI83 register setting for the test pattern to work is written in a HTML script and can be found in the attachment. 

Please give some advice, is there somthing else should be considered? 

Fullscreen SN65DSI83_D101AXHDIF-CC003_Qualcomm_TestPatern.xml Download 
<adapter>
    <configure i2c="1" spi="1" gpio="0" tpower="1" pullups="1"/>
    <i2c_bitrate khz="100"/>
	
	<i2c_write addr="0x2d" count="2" radix="16" nostop="1">00 08</i2c_write>
    <i2c_read addr="0x2d" count="9"/>
	<sleep ms="10"/>
	
	<i2c_write addr="0x2d" count="2" radix="16">09 00</i2c_write>
	
	<!-- Clock Source: bit0 = 1 using MIPI clock 37.5MHz ~ 62.5MHz -->
	<!-- <i2c_write addr="0x2d" count="2" radix="16">0A 03</i2c_write> -->
	<!-- DSI_CLK_DEVIDER = 4, so if D-PHY clock is 200MHz, LVDS clock is 50MHz -->
	<!-- <i2c_write addr="0x2d" count="2" radix="16">0B 18</i2c_write> -->

	<!-- Clock Source: bit0 = 1 using MIPI clock 25MHz ~ 37.5MHz -->
	<i2c_write addr="0x2d" count="2" radix="16">0A 01</i2c_write>
	<!-- DSI_CLK_DEVIDER = 8, so if D-PHY clock is 200MHz, LVDS clock is 25MHz -->
	<i2c_write addr="0x2d" count="2" radix="16">0B 38</i2c_write>
	
	<i2c_write addr="0x2d" count="2" radix="16">0D 00</i2c_write>
	
	<i2c_write addr="0x2d" count="2" radix="16">10 26</i2c_write>
	<i2c_write addr="0x2d" count="2" radix="16">11 00</i2c_write>
	<!-- CH_DSI_CLK_RANGE is 0x28 means 200MHz to 205MHz -->
	<i2c_write addr="0x2d" count="2" radix="16">12 28</i2c_write>
	<i2c_write addr="0x2d" count="2" radix="16">13 00</i2c_write>
	<!-- Data format: 24bit Format 1, DE,H-Sync, V-Sync, all positive polarity -->
	<i2c_write addr="0x2d" count="2" radix="16">18 7A</i2c_write>	
	<!-- Increase differential output voltage swing for LVDS channel A.-->
	<i2c_write addr="0x2d" count="2" radix="16">19 08</i2c_write>
	<i2c_write addr="0x2d" count="2" radix="16">1A 03</i2c_write>
	<i2c_write addr="0x2d" count="2" radix="16">1B 00</i2c_write>
	
	<i2c_write addr="0x2d" count="2" radix="16">20 00</i2c_write>
	<i2c_write addr="0x2d" count="2" radix="16">21 05</i2c_write>
	<i2c_write addr="0x2d" count="2" radix="16">22 00</i2c_write>
	<i2c_write addr="0x2d" count="2" radix="16">23 00</i2c_write>
	<i2c_write addr="0x2d" count="2" radix="16">24 20</i2c_write>
	<i2c_write addr="0x2d" count="2" radix="16">25 03</i2c_write>
	<i2c_write addr="0x2d" count="2" radix="16">26 00</i2c_write>
	<i2c_write addr="0x2d" count="2" radix="16">27 00</i2c_write>
	<i2c_write addr="0x2d" count="2" radix="16">28 20</i2c_write>
	<i2c_write addr="0x2d" count="2" radix="16">29 39</i2c_write>
	<i2c_write addr="0x2d" count="2" radix="16">2A 00</i2c_write>
	<i2c_write addr="0x2d" count="2" radix="16">2B 00</i2c_write>
	<i2c_write addr="0x2d" count="2" radix="16">2C 0A</i2c_write>
	<i2c_write addr="0x2d" count="2" radix="16">2D 00</i2c_write>
	<i2c_write addr="0x2d" count="2" radix="16">2E 00</i2c_write>
	<i2c_write addr="0x2d" count="2" radix="16">2F 00</i2c_write>
	
	<i2c_write addr="0x2d" count="2" radix="16">30 02</i2c_write>
	<i2c_write addr="0x2d" count="2" radix="16">31 00</i2c_write>
	<i2c_write addr="0x2d" count="2" radix="16">32 00</i2c_write>
	<i2c_write addr="0x2d" count="2" radix="16">33 00</i2c_write>
	<i2c_write addr="0x2d" count="2" radix="16">34 23</i2c_write>
	<i2c_write addr="0x2d" count="2" radix="16">35 00</i2c_write>
	<i2c_write addr="0x2d" count="2" radix="16">36 03</i2c_write>
	<i2c_write addr="0x2d" count="2" radix="16">37 00</i2c_write>
	<i2c_write addr="0x2d" count="2" radix="16">38 23</i2c_write>
	<i2c_write addr="0x2d" count="2" radix="16">39 00</i2c_write>
	<i2c_write addr="0x2d" count="2" radix="16">3A 05</i2c_write>
	<i2c_write addr="0x2d" count="2" radix="16">3B 00</i2c_write>
	<!-- Enable LVDS CHA_TEST_PATTERN generation  -->
	<i2c_write addr="0x2d" count="2" radix="16">3C 10</i2c_write>

	<i2c_write addr="0x2d" count="2" radix="16">3D 00</i2c_write>
	<i2c_write addr="0x2d" count="2" radix="16">3E 00</i2c_write>

	<i2c_write addr="0x2d" count="2" radix="16">0D 01</i2c_write>
	<sleep ms="10"/>
	<i2c_write addr="0x2d" count="2" radix="16">09 01</i2c_write>

	
	<!--     <i2c_write addr="0x50" count="2" radix="16">00 00</i2c_write>
    <sleep ms="10"/>
    <i2c_write addr="0x50" count="2" radix="16">01 01</i2c_write>
    <sleep ms="10"/>
    <i2c_write addr="0x50" count="2" radix="16">FF FF</i2c_write>
    <sleep ms="10"/> -->
	
	
</adapter>

  • 0
    TI__Mastermind 18655 points

    Hello Nestor,

    Please, double check that your systems follows the initialization sequence requirement. It states that the host must drive DSI outputs to LP11 prior the transaction to HS mode. Therefore, make sure you have the MIPI inputs driven to LP11(both P and N pairs of all MIPI DSI differential pairs to single ended high ~1.2V) prior to asserting EN pin.

    Provide the status of IRQ Registers.

    Regards

  • 0 in reply to Joel Jimenez0
    Intellectual 985 points

    Hello Joel,

    Thank your for your quick response.

    We modified the setup sequence as you mentioned. Following exactly as described in the datasheet section 7.4.2

     But it showed no effect. 

    By reading the IRQ registers, we get the following readings, before and after the init sequence modification.

    0xE0(reads 0x00)      0xE1(reads 0x00)       0xE5(reads 0x81) 

    So, 0xE5 content is 0x81 means that there is CHA_SYNCH_ERR as well as PLL_UNLOCK.

    what cause could it be? how to fix those errors?

    I noticed that it mentioned in section 7.4.6, that transition to LP mode is recommended on every video line. 

    But it also mentioned that in order for the DSI83 to work using D-PHY clock, the D-PHY clock should be continuous(free-running). In our setup, the D-PHY clock is HS mode all the time, no transition to LP mode implimented. could that be the root of this issue?

    So, how should we conifgure the D-PHY clock correctly?

  • 0 in reply to nestor lee
    TI__Mastermind 18655 points

    Hi Nestor,

    The requirement is that the D-PHY clock lane must be continuous in HS mode when the channel A clock is used as the LVDS clock source.

    Can you share a scope capture showing EN terminal, DA0P, and DACP when EN is asserted?  We need to confirm if  your are meeting the timing requirements stated in the Figure 4.

    The PLL_UNLOCK is a CLK issue, but if you are getting test pattern correctly, it may be been set during the initial setup. You have to check if this bit is being set back to 1 after it's cleared. If you continue detecting the PLL_UNLOCK error, the input CLK is likely having a signal integrity issue.

    Regards

  • 0 in reply to Joel Jimenez0
    Intellectual 985 points

    Hi Joel,

    The scope capture is as follows, the yellow waveform is DACP and the blue one is DA0P, the EN is turned on at the  "T" marked time line in the uppper left corner of the capture.

    So it's DA0P and DACP comes first, and after around 18ms, the EN signal was issued. and more than 210ms later, the MIPI data lane switched from LP11 to HS mode.

    Besides, I checked the IRQ register 0xE5, if DSI83 outputs test patern, the value is 0x00, and if the test patern feature is turned off, the 0xE5 reads back a value of 0x80 after being cleared. So it means a CHA_SYNCH_ERR error  occured.

  • 0 in reply to nestor lee
    TI__Mastermind 18655 points

    Hi Nestor,

    It looks like the DSI Clk (DACP) signals is not driven to 1.2V ( LP11)  when the EN terminal is asserted.

    Regards

  • 0 in reply to Joel Jimenez0
    TI__Mastermind 18655 points
    Nestor,

    Is this issue solved? Do you have any update?

    Regards
  • 0 in reply to Joel Jimenez0
    Intellectual 985 points

    Joel,

    Not yet. Customer is debugging the MIPI interface on MSM8939 now, and the requested LP11 mode on MIPI clock is no yet solved. Since customer is busy doing other things these days, so the progress may be a little delayed.

  • 0
    Expert 2290 points

    Do you remember what you had to do to get your Qualcomm part to output a continuous DSI clock?  I'm facing a similar issue and that is all that's holding me back at the moment :)

    Thank you