DSI issues driving a SN65DSI86

[balint]

Dear forum mmebers,

I am trying to use an STM32U5G9 MCU to drive a Ti SN65DSI86 DSI to eDP converter with no success.

Previously I have evaluated the SN65DSI86 with a Xilinx FPGA as a DSI source where it was working perfectly from 640x480 to 1920x1200 resolution at 60Hz refresh rate. The line rate was up to 900Mbps/lane. At 640x480@60Hz I used 2 lanes and 250Mbps/lane. The SN65DSI86 can be configured to output the VSYNC on one of its GPIO which can be used to verify that DSI data is at least partially correct.
I have also succesfully evaluated the STM32U5G9J-DK1 evaluation board with its display (round, 480x480) so both the STM32U5G9 and Ti SN65DSI86 works.

Now we have manufactured an extension board for the STM32U5G9J-DK1 which has the Ti SN65DSI86 and a DisplayPort connector to drive a monitor. I am trying to use 640x480@60Hz and the STM32's internal test pattern generator in the DSI. Now I can see that the 60Hz VSYNC signal is present on the SN65DSI86 but it gives no picture at all.
What I can not understand if the VSYNC signal is present in the SN65DSI86 DSI receiver why the image is not transmitted to the monitor.
Do somebody have an idea whether I had configured something wrong? (Attached the DSI config.)

[balint]

One more thing: The Ti SN65DSI86 also have a HSYNC output. I've put an oscilloscope on it and I've seen that there is HSYNC in the vertical back porch area but nothing after that nor in the active area neither in the front porch. The next VSYNC is fine and the HSYNC pattern is also fine until the end if the back porch. I use non burst mode with events.

[mathiasmarkussen]

Have you tried to enable the DSI interrupt for debugging?

You should be able to inspect the DSI host handle and see if it's in an error state.

Would you mind sharing s screenshots of the configuration in CubeMX?

[balint]

Dear Mathias!

I've enabled DSI error interrupts but there is no error.

I've configured the SN65DSI86 DSI receiver to output both the VSYNC and HSYNC on its GPIOs. I can see all VSYNC signals but the HSYNC stops at the beginning of the active area of each line.
On the oscilloscope I can see 36 HSYNC pulse after a VSYNC pulse. The vertical sync width is 2 lines and the vertical back porch is 33 lines so I assume the HSYNC stops after the first line in the active region.

The SN65DSI86 shows two errors:
- CHA_DATATYPE_ERR: When the DSI channel A packet processor detects a unrecognized DSI data.
- LOSS_OF_DP_SYNC_LOCK_ERR: This field is set whenever the DP sync generator has lost lock with the DSI sync stream.
However I guess the LOSS_OF_DP_SYNC_LOCK_ERR is a consequence of the first error.

I've attached the screenshots from CubeMX. However I had to modify one thing manually: On the Display Interface tab the Number of chunks is incorrect: It should be 4 I guess since the video packet size x number of packets = number of pixels per line. (160x4=640)

Thank you for your help!

[mathiasmarkussen]

What version of CubeMX are you using?

Can you share your LTDC configuration as well?

For me, using CubeMX 6.14, the number of chunks is calculated correctly in the UI as shown in my screen shot. I could definitely imagine getting problems (especially related to timing) if the any parameter is set up to support 25600 pixels per line (160*160 as shown in your screen shot), but is only set up to deliver to 640.

[balint]

Dear Mathias,

I've downloaded the 6.14.1 version but the number of chunks is still calculated wrong on UI. However in the code I've modified it manually to 4 even in the code attached to my opening question.

I haven't used LTDC in this project yet since I'm trying to generate the test image with the internal test pattern generator of the DSI host controller.

Do you maybe think something else could be wrong in the generated code besides the number of chunks?

Thanks!

[mathiasmarkussen]

Hello balint,

I would advise that you set up the LTDC as you would like to use it when you move on from the test patterns. There are some clock requirements that you need to mind once you want to use the LTDC to feed the DSI host (that is the intended way to send pixels to the DSI host in video mode as well as "adapted command mode"), which you can read about in the U5 reference manual, page 1739-1740.

But i do notice when comparing my experiments with your initialization code that you have VidCfg.HorizontalLine = 800, whereas I get a much larger value when setting up the Display parameters and a single full screen layer in CubeMX. The reason is that the value should be defined as lane byte clock cycles rather than pixels (which is impacted by the clock requirements mentioned above), but CubeMX takes care of this conversion, as well as other conversions that may be needed, once everything is set up correctly, and you will ultimately need to set up the LTDC at some point to get frame buffer output. I have attached a screen shot of a table from the reference manual with the requirements to output frames, including using the test pattern generator. This is from the reference manual, page 1766 in the section "44.11 Functional description: video mode pattern generator".

Unfortunately, I am not aware of any other way of getting the fields to repopulate with the calculated values than using the reset configuration button on the DSI host configuration screen or disabling and reenabling the DSI host, which will have the same effect, you will have to make any changes you previously made to the configuration again.

[balint]

Dear Mathias,

Thanks for your help, now the LTDC and DSI works almost correctly.

There was two problems until now. Initializing the LTDC helped and as soon as it was on I could see the HSYNC pulses during the entire frame not just before the active period. I guess I've misunderstood the reference manual which stated that the video pattern generator of the DSI host can do "Vertical and horizontal color bar generation without LTDC stimuli".
I've also needed to reset the DSI configuration in the CubeMX to import the timing data from the LTDC and calcuate the DSI timings. I was not aware of the timings should be given in lane byte clock. (I've also updated the CubeMX.)

However I still have a problem: I use the LTDC and DSI to output an 640x480 image from a frame buffer. The image is shown on my monitor but it is shifted: The right ~1/6 of the picture is on the left side of the monitor. I attach a photo of it.
Both the LTDC clock and lane_byte_clk is 31.25MHz so as I understand I can use the same values for DSI HSA/LTDC Hsync width, DSI HBP/LTDC HBP and DSI HLINE/LTDC total width. It gives a 74.4Hz refresh rate on the monitor.
If I've changed the packet size and the number of chunks the colors of the picture are mixed and/or shifted to a different position. In case of the shifted image PacketSize=16 and NumberOfChunks=40 and when the colors are also bad I've used PacketSize=128 and NumberOfChunks=5. The DSI sink device has a line buffer however its datasheet does not define its size.
Do you maybe have an idea what can be the problem with it?

Thank you!

[mathiasmarkussen]

That is a weird look. I assume you have just a single buffer that is not being modified?

Otherwise, I'd fiddle with the horizontal porch settings and see if that has any effect, it looks like there is some part of a previous pixel line being repeated on the next - or maybe the other way around. Did you have this problem with the test patterns? If not, I'd just change it for the LTDC, I assume the part about LTDC stimuli means that the image is created by the DSI host without any pixel input from the LTDC, but the timings need to be correct for that to work.

You should probably also monitor both the LTDC and DSI host error interrupts for underruns etc.