SK-AM62P-LP: LVDS single link with DSS managed by WKUP_R5FSS0

Part Number: SK-AM62P-LP
Other Parts Discussed in Thread: AM62P, SYSCONFIG

Tool/software:

Hello.

I need to manage a single link LVDS display (4 lanes + clock) from the wakeup R5.

The issue is that when switching to single link (from the syscfg), the LVDS common mode voltage drops to 0.6V

Changing under "OLDI configration" the "Dual Mode" to enable, the LVDS common mode voltage is (as expected) 1.2V.

The datasheet says that the LVDS common mode voltage is 1.125V (min) - 1.375V (max).

Why changing the LVDS configuration to single link drops the Vocm to 0.6V? How to prevent that?

Thank you!

Francesco

  • Hi Francesco, which FPD-Link is currently connected?

  • There is no FPD-Link involved. Direct connection of a display to the LVDS lanes coming out of the SoC.

  • Hi Francesco, 

    Thank you for the inputs.

    Let me check with the team.

    Regards,

    Sreenivasa

  • Hi Francesco,

    Do you have 100ohm resistors across data and clock differential pairs? Is the LVDS common mode voltage dropping to 0.6V being observed on the oscilloscope? If so, are you using high impedance probes or 50ohm terminated probes?

    Best regards,

    Luis Parga

  • Hi Luis,

    I'm a colleague of Francesco's. I'm part of the HW team, and I can answer these questions for you. The termination resistors (100 ohms) are on the TFT side. We tested them both with the active probe and a normal probe, and the result was the same. We observed the difference when we switched from dual link to single link. When the DSS_OLDI_CFG register is configured to operate in single link, the result differs from that declared on the datasheet. When we switched to dual link, the behavior was as declared. We also tested without the TFT, and the situation remained unchanged. The value of register 3020 A160h was set to 0x1103. Can you help us understand where we're going wrong?

    Best Regards,

    Alexandru Ilinca

  • Hi Alexandru,

    Could you help to provide a register dump of the below registers for both dual and single link cases?

    We want to understand what the differences are termination wise.

    Best regards,

    Luis Parga

  • Hi Luis,

    We dumped the registers and bellow you can find the results.

    single link:

     

    root@dsb24f:~# devmem2  0x00108600 w |grep Read
    Read at address  0x00108600 (0xffffa8e49600): 0xC1043008
    root@dsb24f:~# devmem2  0x00108604 w |grep Read
    Read at address  0x00108604 (0xffffbd742604): 0xC1043008
    root@dsb24f:~# devmem2  0x00108608 w |grep Read
    Read at address  0x00108608 (0xffff83fb1608): 0xC1043008
    root@dsb24f:~# devmem2  0x0010860C w |grep Read
    Read at address  0x0010860C (0xffff9ea9a60c): 0xC1043008
    root@dsb24f:~# devmem2  0x00108610 w |grep Read
    Read at address  0x00108610 (0xffffad44f610): 0xC1043008
    root@dsb24f:~# devmem2  0x00108620 w |grep Read
    Read at address  0x00108620 (0xffff8f287620): 0xC1043008
    root@dsb24f:~# devmem2  0x00108624 w |grep Read
    Read at address  0x00108624 (0xffff87196624): 0xC1043008
    root@dsb24f:~# devmem2  0x00108628 w |grep Read
    Read at address  0x00108628 (0xffffb4098628): 0xC1043008
    root@dsb24f:~# devmem2  0x0010862C w |grep Read
    Read at address  0x0010862C (0xffff83b6562c): 0xC1043008
    root@dsb24f:~# devmem2  0x00108630 w |grep Read
    Read at address  0x00108630 (0xffffb7c85630): 0xC1043008

    dual link:

     

    root@dsb24f:~# devmem2  0x00108600 w |grep Read
    Read at address  0x00108600 (0xffff98b4a600): 0xC1043008
    root@dsb24f:~# devmem2  0x00108604 w |grep Read
    Read at address  0x00108604 (0xffffb09b5604): 0xC1043008
    root@dsb24f:~# devmem2  0x00108608 w |grep Read
    Read at address  0x00108608 (0xffff9facd608): 0xC1043008
    root@dsb24f:~# devmem2  0x0010860C w |grep Read
    Read at address  0x0010860C (0xffffbace460c): 0xC1043008
    root@dsb24f:~# devmem2  0x00108610 w |grep Read
    Read at address  0x00108610 (0xffffa0b39610): 0xC1043008
    root@dsb24f:~# devmem2  0x00108620 w |grep Read
    Read at address  0x00108620 (0xffffaf8fd620): 0xC1043008
    root@dsb24f:~# devmem2  0x00108624 w |grep Read
    Read at address  0x00108624 (0xffff847c4624): 0xC1043008
    root@dsb24f:~# devmem2  0x00108628 w |grep Read
    Read at address  0x00108628 (0xffffa9e93628): 0xC1043008
    root@dsb24f:~# devmem2  0x0010862C w |grep Read
    Read at address  0x0010862C (0xffffa011862c): 0xC1043008
    root@dsb24f:~# devmem2  0x00108630 w |grep Read
    Read at address  0x00108630 (0xffff8daa3630): 0xC1043008

    Best Regards.

    Alexandru Ilinca

  • Hi Alexandru,

    I am working on replicating your issue. I will advise in 1-2 days.

    Best regards,

    Luis Parga

  • Hi Alexandru,

    Thanks for sharing the register dump. I confirm I see the same on my end for the provided registers.

    I am still in the process of getting my AM62P OLDI setup fully working. However, below is what I am seeing so far using an OLDI test binary from a different device. Unfortunately, I have not been able to get history on it to understand whether this is with single or dual link. The below waveform is OLDI0_CLK0P when at 165MHz. Regardless of single or dual link, the expectation is for VOCM and below measurements from waveform to remain the same.

    I should be able to have my AM62P OLDI CCS project fully working by tomorrow. In the meantime, do you mind sending me the equivalent single ended measurement for both single and dual link for your system? Also, when making this VOCM measurements, can you confirm the display is not connected? Are you seeing VOCM decreased for both clock and data?

    The project from A53 I am working on enabling does not interface with SysConfig. Do you mind sharing how you set SysConfig for both single and dual link?

    The below is what I see as default on my end.

    Best regards,

    Luis Parga

  • Hi Luis,

    In the meantime, we also tested it on the TI evaluation board and we have the same behavior. The measurements were made both with and without the display, and the change we see is that of the amplitude of the signal due to the presence of the termination resistance that is present on the panel. The behaiviour is the Same for data and Clock. We also note that on the D3 data line the common mode is at about 200 mV. but when it is reconfigured to dual link, the VOCM returns to 1.2V

    Below you will find the acquisitions of our board and those made on the evaluation board:

    Measurements on our electronic board:

    Single link:

        D0 without TFT

         D0 with TFT

    Dual link:

       D0 without TFT

    D0 with TFT

    Measurement on the TI Evaluation Board

    Single Link

    D0 without TFT

    Dual link:

    D0 without TFT

    In the Figure below you can find the acquistion on D3 on the TFT and our Board

    On Sysoconfig the setting are as in the figure below and when dual mode sync is selected the configuartion changes to Dual Link 24 bit automaticaly.

    Best Regards,

    Alexandru Ilinca

  • Hi Alexandru,

    Thanks for the scope captures above. I was able to configure for single link with pixel clock at 165MHz and 1920x1080 pixel resolution. I am able to see the correct VOCM. Please see below.

    I am not sure what is wrong yet with your settings. Let me consult with other experts on Tuesday (after our Monday holiday), and I'll get back to you then. We might need a conference call on Wednesday for us to audit your setup.

    Best regards,

    Luis Parga

  • Hi Alexandru,

    Have you reviewed the below application note which details about the Display subsystem on AM62P and also details about how to configure Single Link OLDI -Independent mode and cloned mode using Linux Device tree.

    https://www.ti.com/lit/an/sprads3/sprads3.pdf

    Hope this helps.

    Best Regards,

    Suren

  • Hi Suren! Yes, we have reviewed that application note. The point is that we are configuring the DSS0 on the R5 wakeup MCU. Even if we do not start Linux at all we observe the wrong VOCM on the LVDS lines.

  • Hi Luis, could you please share your setup / the changes you made to make it work on single link? Did you work on the R5 or Linux?

    A technical call may be helpful. Thank you!

  • Hi Alexandru,
    We are currently running some more tests internally (we tried with baremetal as well as A53 Linux driven DSS and single link VOCM seem to be fine), we will also try for R5 RTOS based example. 
    The results of this test are important before we proceed with a technical call. Please give us a day or two more for our internal debug.

  • Hi Alexandru, Francesco,

    My apologies for the delay on this. We were finally able to replicate the issue being observed on your end. Vocm is being dropped to half what it should be when using RTOS (MCU_PLU SDK) with R5 core. Since this behavior is not observed with Linux SDK using A53, we believe this is software issue and unrelated to IP itself. We are looking into getting this corrected with urgency. We will advise in 1-2 days.

    LVDS_CLKP (w/ 100Ohm termination across diff pair) in Single link w/ RTOS (MCU_PLUS SDK) using R5 w/ AM62P SKEVM:

    Best regards,

    Luis Parga

  • Hi Luis,

    Thanks for your support. In the meantime, as soon as a colleague of ours returns from vacation, we'll try to run a test with the Linux SDK. We look forward to hearing from you.

    We look forward to hearing from you regarding the RTOS (MCU_PLUS SDK) using R5.

    Best Regards

    Alexandru Ilinca

  • Hi Alexandru,

    We have not gotten to the root cause of this issue yet. This has been escalated to a wider team to get to the root cause as fast possible. Issue is being treated with very high urgency. Please let us know your findings with A53 when using Linux SDK. I will provide another update tomorrow.

    Best regards,

    Luis Parga

  • Hi Alexandru,

    We have found the issue. It turns our the MCU+ DSS driver for OLDI bridge was missing to enable the 1.2V IO bandgap reference for the OLDI single link mapper configuration. After enabling this, I am now able to see Vocm of ~1.2V. A patch will be provided shortly by Divyansh for you to try on your end.

    Best regards,

    Luis Parga

  • Hi Alexandru,
    https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/791/0001_2D00_drivers_2D00_dss_2D00_dss_5F00_soc.c_2D00_Fix_2D00_OLDI_2D00_power_2D00_down_2D00_control_2D00_lo.patch

    Please use this patch in MCU+SDK.
    If you are using CCS, the following steps maybe helpful to use the patch:
    1. Apply the above patch in the MCU+SDK linked to your CCS project.
    2. Run the following commands:

    cd <CCS linked MCUSDK>
    make libs -sj PROFILE=debug

    3. Rebuild your CCS project.
    4. Flash the binaries and test.

  • Hi Divyansh,

    you patch works like a charm!

    If you happen to come in Passignano, write to us and we'll offer you a drink!

    Have a nice day,

    Francesco