AM625: DSS Videoport Sync Lost Recovery Steps

Hello,

Thank you for the query.

Are you seeing this behavior in the evaluation board or custom board?

Regards

Rajashri

We have seen this on both the AM62x EVM and our own board. We also saw it on the AM65x EVM, which we worked with before the AM62x became available.

Hello,

I am working internally to assign it to the video expert to check on the software to restore the DSS Videoport without doing a power cycle after Sync Lost event occurs.

Regards

Rajashri 

Hello Grant Griffin, 

Thank you for waiting. We are checking internally on the reported issue and have a few question listed below

1. What is the frequency that you are requesting for the VP1? And what is the pixel frequency that you are expecting for the display that you are working on?
2. What is the mode of the OLDI display you intend to work on? (single mode – single link, duplicate mode – single link, OR single mode – dual link?)
3. Are you enabling the required OLDIs by configuring the 0^th bit of registers at addresses 0x3020A160 (for OLDI 0) and 0x3020B160 (for OLDI 1)

We also saw it on the AM65x EVM, which we worked with before the AM62x became available.

Did you resolve this on the AM65, If yes do you have some inputs.

Regards,

Sreenivasa

Hello Grant Griffin, 

Checking if you had a chance to look at the thread above.

Regards,

Sreenivasa

Thank you for responding. Here are the LCD parameters that we are using:

            68,                     /* pixel clock, in MHz          */
            40,                     /* horizontal sync width        */
            55,                     /* horizontal front porch       */
            50,                     /* horizontal back porch        */
            2,                      /* vertical sync width          */
            8,                      /* vertical front porch         */
            6,                      /* vertical back porch          */
            60                     /* refresh rate, in Hz          */

We are using only OLDI 0, and have set the configuration bit accordingly. Here is the full set of OLDI parameters we are using:

Configure the OLDI
    -"Deassert" module reset
    -Type C = single link 24 bit
    -Enable OLDI

Values left as default/0:
    -Test pattern config off
    -dual mode sync off
    -loopback data off
    -loopback enable off
    -DSS bit depth is 18 bit LVDS only - don't care
    -polarity active high
    -dual mode master - don't care
    -single mode
    -source channel VP0

Hello Grant Griffin, 

Thank you for the inputs. Let me have this verified internally and update you.

I there a flow chart or psudo code to describe the steps you are following.

Regards,

Sreenivasa

We have tried many different methods, without success. Currently, we:

- Activate DSS soft reset by setting the SOFTRESET bit of the DSS_SYSCONFIG register described in Table 12-5392 of SPRUIV7.

- Wait for all RESETDONE bits in DSS_SYSSTATUS register described in Table 12-5394 to read as '1'.

- Restart the DSS output via its GO and output ENABLE bits.

Hello Grant Griffin, 

Thank you for the inputs. Let me have this verified internally and update you.

Regards,

Sreenivasa

Hello Grant Griffin, 

Bellow is our expert assessment for your review. Can you also please make sure  you ae following the terminations recommended in the datasheet.

It seems very likely that the “system restart” on JTAG is not completely/properly resetting the chip and messing up with the clock synchronization between the DSS and panel.

 Are you issuing a CPU reset or System reset on JTAG?

1. Which OS (RTOS/Baremetal/Linux) are you running on the A53 cores  (main domain)?
2. Are you trying to access DSS from any other domain (MCU domain)?
3. Can you make sure the code clears the interrupt after it pops up?

Regards,

Sreenivasa

Hello Grant Griffin, 

Please let me know if you have some inputs.

Regards,

Sreenivasa

1. Bare metal

2. No: it is being accessed only from the A53 core 0

3. Yes, we have done that. However, as we had anticipated, the DSS output signal is not directly affected by the related DSS interrupts.

Hi Sreenivasa,

We have not experienced the problem of the DSS lost output sync lately, apparently due to the fact that we have adopted the practice of restarting the AM625 processor each time it runs, either by restarting the Lauterbach debugger when debugging, or by cycling power when booting from flash. In effect, we do not need to recover from lost sync because it does not occur with that methodology.

However, our application is a safety-critical system, so in the event that we detect a loss of DSS sync at runtime, our software will need to recover from that via the built-in DSS reset features, as described in the AM62x TRM. Although I appreciate your responses on this question, we still have not received any information about how to recover from that successfully via the DSS reset features. TI ultimately will need to resolve this issue in order to meet the needs of their customers with safety-critical applications. Since the AM62x has a lot of built-in safety related features, it appears that TI considers that an important application area for the AM62x.

Since we have a successful mitigation during our current development phase, we am not currently focusing on this problem. I have provided all information I have on this issue, and our project priorities are such that I cannot spend any additional time responding to this issue for now. So, I do not plan to pursue it further in the near term.

However, I have not marked it as "resolved" because TI has not yet provided any useful information on this issue. I believe that TI should be able to pursue this further without my involvement for the time being, so please do not request any additional information from me before TI provides me with something useful to try. Even then, I may not be able to respond in a timely manner.

Regards,

Grant

Hello Grant Griffin, 

Thank you for the updates.

Noted your priorities. Please let us know if you do some further testing or have some observations.

I will share the inputs internally.

Regards,

Sreenivasa