SN65DSI84-Q1: The DSI data CRC error detection mechanism and the potential causes in the DSI source

Hi,

The system always report CHA_CRC_ERR in 0xE5[6] bit when SOC  from MTK wake-up from the STR mode and need to re-config DSI84.

*** In this particular instance, does the color bar show up if they switch to the DSI84-Q1 internal pattern generation?

When SOC  from MTK wake-up from the STR mode

*** Are they using the DSI CLK as the clock source? In this case, do they hold the DSI84-Q1 EN low and make sure the SOC DSI data lane is in LP11 state and the clock is in HS continuous state before taking the DSI84-Q1 out of reset? Do they set the SOFT_RESET bit before the SoC starts the video stream?

Thanks

David

Hi David

For your question 1, even there are CHA_CRC_ERR error, but the display show normally after SOC quit from STR mode and re-initial DSI84 with the same one during the system first power up. 

For your question 2, below captured waveform shows that customer follow the requirements of the initialization sequence from seq 1 to seq4. 

Yellow-- EN, Green-- DSI CLK, Blue- DSI data (measured with differential-end probe) and have asked customer to measure DSI data with the single-end probe to check if SOC output LP11 before EN is pulled-low.

Will double check if customer meet the requirements from seq 7 to seq 10? 

BUT would you help firstly share your comments on customer's questions?

   So customer wanted to know how SN65DSI84-Q1 detect the CRC error in DSI data lanes. And would you help share the potential causes to help customer to investigate the next step at SOC side?

Thanks 

Hi,

So even with the CHA_CRC_ERR error, but the display show normally after SOC quit from STR mode and re-initial DSI84 with the same one during the system first power up? If this is the case, can they please write 0xFF to register 0xE5 to clear the status register and see if the CHA_CRC_ERR error is still being reported? 

I also want to clarify when you say display show normally, is this the DSI84 internal test pattern or the video data from the SoC?

Thanks

David

Hi David

Thanks for your quick response!

The DSI84 input is the video data from the SoC. 

But in the DSI84 initialization sequence, require 0xE5 must be 0x00 at the last  seq 11.  Even the panel can display normally but customer still wanted to find why DSI CRC error is reported 

Still expect to get your comments on customer's question firstly!! Let's focus on them firstly. 

So customer wanted to know how SN65DSI84-Q1 detect the CRC error in DSI data lanes. And would you help share the potential causes to help customer to investigate the next step at SOC side?

Thanks . 

Hi,

The status register 0xE5 may get set during the DSI84 initialization. So once the initialization has been completed, we need to clear it first. Any error reported after the status register 0xE5 has been cleared is the real error. 

For CHA_CRC_ERR: This is most likely due to issues in the communication channel itself. This can be due to a corrupted signal, bad cable connections, and improper setup of the bridge.

Thanks

David

Hi David

We doubled check that SOC and the initial code completely match the DSI84 initialization sequence and no bad cable connections( The DSI traces are connected with SOC and DSI84 and no any SI issue in DSI trances). 

Customer need to know how DSI84-Q12 implement the CRC error detection of DSI incoming steams from SOC. Customer have not get the direct answer to this question in previous thread from BU team. Would you help check it with design team to share the comments?

Below just is an idea from customer. Customer found that there is the DSI packet processor inside DSI84. 

And DSI CRC information is in the packet footer based on DSI specification.  DSI84 correctly decode the DSI packet of the incoming streams and get the CRC checksum then check it for CRC error detection. Is it right? 

Thanks 

Hi Ted,

David is currently out of office. I will reassign the thread until he gets back.

Hi Vishesh

 Thanks for your information. Since David is out of office,  who can reply this question? The DHU project will be in DV test, customer pushed TI to provide the answer. 

Thanks 

Hi Ted,

Like David mentioned this could be due to the 0xE5 setting that bit during initialization. It should be cleared afterwards by writing 0xFF to the register. If the customer write this, does this error show again during runtime?

- Ikram

HI Ikram

Yes, this CRC error always show again during runtime even customer write 0xFF to clear but display was good. 

So customer need to get to know how DSI84-Q1  implement the CRC error detection of DSI incoming steams from SOC. Pls check with design team and provide the comments ASAP.  Pls focus on this request. 

Thanks 

Hi Ted,

To detect possible errors in transmission, a checksum is calculated over each data packet. The checksum is realized as a 16-bit CRC. The DSI84 will use this to check against the CRC being included in the received data packet and flag an CRC error if the calculated CRC does not match with the received CRC.

Best regards,
Ikram

HI Ikram

So the job that a checksum is calculated over each data packet is done by DSI84 itself, is it right?

Thanks

Yes Ted, this is done by the DSI84 itself.

Hi Ikram

Does DSI84-Q1 have the requirement on EOTp for the DSI incoming stream?

And does DSI84-Q1 have the registers to get the checksum value for the incoming stream?

Thanks 

Hi Ted,

Yes, there is a requirement for EOT packets and the EOT sync errors are included in the 0xE5 register bit 3.

There is no register to check the checksum value.

Best regards,
Ikram

Hi Ikram

DSI84-Q1 supports the DSI streams with EOT packets or streams without EOT packets from SOC source and no any DSI84 CSR configurations for EOT packets, is it right?

Don't find any requirement on EOT packets in the datasheet and application. 

Thanks