SN65DSI83: SN65DSI83 sync error with STM32

Hello I.K.

I'm attaching the .dsi and panel datasheet. Renamed the .dsi to .txt as the forum didn't allow to upload directly.

Thanks.

F__规格书_COG-TA10MZXH-01_NEW SPEC_COG-TA10MZXH-01 specification.pdf

%CHIP1%PVCA%PMCA%RPCA1024%RLCA600%PVCB%PMCB%RPCB%RLCB%LVCM0%HPWA70%HBPA80%HFPA30%HACA1024%HTOA1204%HPWB%HBPB%HFPB%HACB%HTOB0%VPWA10%VBPA30%VFPA15%VACA600%VTOA655%VPWB%VBPB%VFPB%VACB%VTOB0%PCKN25%LCKS0%RCKM%MULT0%DCKA200%DIVI7%LCKR25.0%FMTA1%DEPA0%HSPA1%VSPA1%BPPA0%FMTB1%DEPB0%HSPB1%VSPB1%BPPB0%PRDA1024x600%PRDBx%DSCM0%LREO1%LRCE1%LPCA0%BMCA1%SMCA1%LPCB0%BMCB0%SMCB0%DHPA70%DHBA80%DHFA30%DHAA1024%DHTA1204%DHPB%DHBB%DHFB%DHAB%DHTB%DVPA10%DVBA30%DVFA15%DVAA600%DVTA655%DVPB%DVBB%DVFB%DVAB%DVTB%DDRA200%NOLA1%VIMA2%LCRP%DDRB%NOLB0%VIMB0%RCRP

Hi again I.K.

For making sure about the timings, I asked the manufacturer for their values as they were not present in the specification.

Recalculated the configuration with the tuner and got 56.56us of line time.

Adjusted the DSI clock to match this value, as the tuner showed that at 150MHz DSI clock the burst time will be exacly what I need. Checked with the oscilloscope that the host is sending data with the same line time.

But sn65dsi83 still shows sync error all the time.

What can be the causes for this error?

I'm attaching the new .dsi and timing parameters of the panel.

Regards.

%CHIP1%PVCA%PMCA%RPCA1024%RLCA600%PVCB%PMCB%RPCB%RLCB%LVCM0%HPWA70%HBPA160%HFPA160%HACA1024%HTOA1414%HPWB%HBPB%HFPB%HACB%HTOB0%VPWA10%VBPA23%VFPA12%VACA600%VTOA645%VPWB%VBPB%VFPB%VACB%VTOB0%PCKN50%LCKS0%RCKM%MULT0%DCKA150%DIVI5%LCKR25.0%FMTA0%DEPA0%HSPA1%VSPA1%BPPA0%FMTB1%DEPB0%HSPB1%VSPB1%BPPB0%PRDA1024x600%PRDBx%DSCM0%LREO1%LRCE1%LPCA0%BMCA1%SMCA1%LPCB0%BMCB0%SMCB0%DHPA70%DHBA160%DHFA160%DHAA1024%DHTA1414%DHPB%DHBB%DHFB%DHAB%DHTB%DVPA10%DVBA23%DVFA12%DVAA600%DVTA645%DVPB%DVBB%DVFB%DVAB%DVTB%DDRA150%NOLA1%VIMA2%LCRP%DDRB%NOLB0%VIMB0%RCRP

Hi again.

Did you have time to take a look at the new configuration I.K.?

I'm attaching the interrupt event capture I mentioned in last post. Yellow trace is lane 0 positive signal, blue trace is IRQ line.

It always asserts at that point, in the first line of the next frame after it was cleared, it looks to be set after receiving the sync pulse. There is a LP period of 2us between frames.

Best regards.

Hello.

Yes, i forgot to attach it, here you have it. That one is configured for 25MHz LVDS, 200MHz DSI in two lanes, non-burst with pulses. Yellow trace is D0+ and blue is IRQ

Since my first post I have done tests with different clocks, in burst, non-burst with event or pulses and enabling LP mode in different regions. I also tried another prototype unit to discard a damaged chip. And also tried reconfiguring another example for an actual display, instead the one for the HDMI converter.

In all cases I receive this SYNCH interrupt at the start of the frame.

I'm thinking about renting a high end oscilloscope with D-PHY decoding to dig into this deeper as mine is only 100MHz bandwidth.

Best regards.

Hi.

That's it, I made a few boards and tested two of them, both boards with different SN65DSI83 units show the same behaviour. It is actually the SN65DSI83-Q1 but it is supposed to be the same chip just in QFP and with automotive qualification.

The test pattern works both with DSICLK and with REFCLK, the idea is to use the DSICLK but modified one board with a 25MHz oscillator and tested the external clock as well to discard issues with the DSICLK. Most of the tests have been done with DSICLK as REFCLK didn't show any difference.

With DSICLK the PLL unlock bit is never set so it must be working correctly, also the LVDS clock corresponds with the desired frequency of 25MHz when the test pattern is active.

Best regards.

Hi Angel,

To get a clearer indication of the failure, can you try configuring the internal test register, 0xF9? This field selects which internal signal is output on the IRQ output pin. You can configure this field during the power up. Once the sequence is completed you can know, by monitoring IRQ, if there are internal errors communicating from DSI to LVDS. You can start with trying a_wait_for_vsync. When it is configured the IRQ should remain low after the power-up sequence is completed and the device is operating correctly.

The procedure for getting the status of a_wait_for_vsync from the test mux is the following:

a. Enable IRQ output. Write 0x1 to address 0xE0 to set IRQ_EN=1.

b. Set OUTPUT_TEST_MUX_SEL = 00110 (a_wait_for_vsync) by writing 0x06 to address 0xF9.

c. Observe the test_mux output on the DSI85 IRQ pin.

You can also check for other errors with the below table for IRQ functions.

 

Hi I.K.

I have tested the device as suggested, with test mux set for a_wait_for_vsync the IRQ signal goes low immediately after the VSS event but goes high again after a few microseconds. After checking the times and playing with the configuration parameters it was clear that the low time corresponds to the sync delay time. Initially it was around 1,4 microseconds, for a PCLK of 25MHz this equals to 35 pixel time, setting was at 33 as suggested by dsi tuner.

Increasing the delay time just increases the low time, until it gets to the next HSS. Decreasing it shortens the low time. A value of 1 makes the line go high all the time and a value 0 gives the same result as very long times, rising on next HSS event.

Checked all the mux settings in previous post to try and get more info about the issue, this are the results:

From the mux settings description it looks like a_wait_for_sync should go high only after reset/soft_reset or error conditions. What kind of error can cause this behaviour? IRQ status register still shows only sync error bit.

For making totally sure about the chips I'm ordering a couple of them from another provider, just to discard a bad batch.

Thanks for all your help!

Best regards.