SN65DSI83: DSI83 LVDS Bridge - Sporadic Behavior - No Video

Paul DeMetrotion

Part Number: SN65DSI83

We have a product based on the NXP i.MX8M CPU that also uses the TI DSI83 MIPI DSI Single-Link LVDS Bridge to provide video. We are running the 4.14.78 version of Linux built with the Yocto tools. This code includes a third-party driver (sn65dsi83_brg.c) for the DSI83 coded by CopuLab Ltd.

We have an issue where the LVDS display does not always provide video. Most of the time boards work fine but periodically the backlight will come on but nothing is displayed. One thing we noted is that the CHA_UNC_ECC_ERR bit in register 0xE5 is always set when the display does not work. This indicates an uncorrectable ECC error. We believe the root cause of this failure is in the initialization sequence.

Currently we are reviewing the initialization sequence to ensure it follows the Recommended Initialization Setup Sequence found in the device data sheet on page 15.

We are also reviewing the driver source code. One thing we noted is that the driver does not follow Init seq 10 or 11. This clears and verifies that CSR 0xE5 is a zero. In fact, usually we see multiple error bits set and ignored even when the LVDS video display works.

Is there any hardware and/or software support TI can provide to assist with this issue?

Is there any other Linux driver for this device?

over 4 years ago

0 Ikechukwu Anyiam over 4 years ago

TI__Mastermind 35130 points

Hi Paul,

As you mentioned, no video output is most likely due to an initialization sequence problem. We don't provide software support or drivers, but there is an FAQ here that provides some items that you can check: https://e2e.ti.com/support/interface/f/138/t/852871

Steps 9 through 11 in the sequence are optional and do not need to be included.

Regards,

I.K.

0 Paul DeMetrotion over 4 years ago in reply to Ikechukwu Anyiam

Prodigy 40 points

Thanks for the assistance. We already saw that FAQ link.

As mentioned, most of the time the video works fine. What can cause the CHA_UNC_ECC_ERR error to occur? That bit appears to be a clue to our failure mode.

0 Ikechukwu Anyiam over 4 years ago in reply to Paul DeMetrotion

TI__Mastermind 35130 points

It's possible that can be still be attributed to an initialization sequence violation (many times only a few units become problematic if the sequence isn't followed). Please post an oscilloscope screenshot of your initialization sequence similar to the one provided in the FAQ.

Regards,

I.K.

0 Paul DeMetrotion over 4 years ago in reply to Ikechukwu Anyiam

Prodigy 40 points

I agree that the initialization sequence is the culprit. We have the same unit that passes and fails, not different units.

I have attached the trace you requested minus the DSI_CLK since we have no place to probe that point. I examined this trace and now realize the DSI_DATA is not in the LP11 state.

The Initialization Sequence directs the user to put the DSCLK lanes in HS state and the DSI data lanes in LP11 state.

How is this done?

Is this done by the i.MX8M driving the DSI lines or within the DSI83 device?

0 Paul DeMetrotion over 4 years ago in reply to Paul DeMetrotion

Prodigy 40 points

Forgot the attachement.

0 Ikechukwu Anyiam over 4 years ago in reply to Paul DeMetrotion

TI__Mastermind 35130 points

Hi Paul,

It's very important to ensure the DSI CLK is in HS mode before EN is asserted so that the device can get a proper reset, and remain in HS mode thereafter. Additionally, the DSI data lanes must remain in LP-11 mode until step 8 of the sequence.

All of this must be done by the DSI source (the i.MX8M in your case). The DSI83 has no control over the state of the DSI inputs.

Regards,

I.K.

Interface

Interface forum

SN65DSI83: DSI83 LVDS Bridge - Sporadic Behavior - No Video