cancel
Showing results for 
Search instead for 
Did you mean: 

Problem with MIPI DSI on STM32MP157C CAD package?

OL'He.1
Associate III

Hello!

We have a problem of LCD image quality with our custom STM32MP157C-based board: we see artefacts, wrong colours, ghosts of previous images and rainbows. The LCD is a Winstar WF40CTYAQM, linked with MIPI DSI, much like the Orise Tech LCD of the DK2.

What strange is: when on the DK2, the same LCD shows good images. On our custom board, it shows those artefacts and ghosts in particular. The artefacts happen even if we use the Video Pattern Generator in BER mode, grey stripes.

There is one difference between the boards: the DK2 has an STM32MP157CAC SoC, while our custom board has a STM32MP157CAD SoC, i.e. the package is different and has less pins.

Is there a DSI limitation on the CAD package?

Tests were done in 4 steps:

  1. Show the ST splash screen, with the butterfly and Tux, during 10 minutes. Blue and green are too dark on the CAD package. "IMG_20200603_095341.jpg" <https://lh3.googleusercontent.com/u/0/d/1q3H5w46XKUTFXd5PLQ0CjDe-h4cuGvsA=w1920-h1006-iv1>
  2. Show the SMPTE pattern: artefacts with the CAD package, we see the butterfly and Tux as ghosts through the pattern, colours are dull. "IMG_20200603_100759.jpg" <https://lh3.googleusercontent.com/u/0/d/1q8uZWfzRhZakB02Xp3BtDYwH5w1DWqaO=w1920-h1006-iv1>
  3. Show the colour bars generated by the VPG: no artefact. "IMG_20200603_101357.jpg"<https://lh3.googleusercontent.com/u/0/d/1xVjw50ONyZOncxTFPP980MG1a6GPG3R5=w1920-h1006-iv1>
  4. Show the grey bars generated by the VPG: the artefacts are back. "IMG_20200603_152709.jpg" <https://lh3.googleusercontent.com/u/0/d/1HybonO2isdtK8L4DbumIlCkx-TfcCLFO=w1920-h1006-iv1>
18 REPLIES 18
PatrickF
ST Employee

Hello,

Did you use STPMIC1 as power supply ?

For HW point of view, few basic checks to do:

  • check the correct connection of all DSI signals (e.g. no polarity inversion, PCB length and impedance matching, DSI_TE, display supplies, etc..)
  • STM32MP15x supplies level, noise, PCB tracks/plane, decoupling (especially VDD, VDDA1V8_REG, VDDA1V8_DSI, VDDA1V2_DSI_REG, VDDA1V2_DSI_PHY)

Regards,

In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.
OL'He.1
Associate III

Hello, thanks for the quick answer.

Yes, we use the STPMIC1 for the power supply. And the board is powered at 1.8V.

For the rest, thanks, we'll check those signals and supplies ASAP.

OL'He.1
Associate III

Hello!

We were silent but have worked on this issue during the last months. We have made HW checks on the DSI signals: supplies level and noise, decoupling, eyes diagrams on DSI clock and data lines... everything seems right. We have raised a bit some supply voltage, because our board uses 1.8V for DSI IO: no change. We have found an issue on the length of some DSI differential lines. We have corrected the error and made a new PCB. (This took weeks.)

With the new PCB, we still observe the bad colours, ghosts and rainbows. :( We further work on this problem, any help is welcome.

MM..1
Chief II

Seems as more layers LTDC trouble. Is your code in video mode? How many layers used?

Hi,

Seems you have looked very carefully on all HW aspects, so I still suspect more a SW setting. Did you use (or tried to use) very same clocking/timing settings that on DK2 ?

My feeling is that artifacts, such as logo remaining as watermark on the screen, could only come from either framebuffer mixing on MPU side or on display side (if your display has an embedded framebuffer, like the one on DK2 default display).

Btw, could you elaborate a bit on the "our board uses 1.8V for DSI IO". Does it mean you are using VDD=1.8 and then 1.8V LDO in bypass mode and supplying VDDA1V8_DSI by VDD or antoher 1.8V supply ?

In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.
OL'He.1
Associate III

Hello PatrickF, thanks for your comment.

We are using exactly the same kernel and driver on the DK2 and on our custom board, and the DTB are very similar. AFAIK, the clicking/timing is the same.

I think the ghosts/watermarks are not coming from an image stored in some frame buffer, because it is clearly linked to the amount of time the previous image stays on the screen. If you display the butterfly and tux during 1 second, then switch to the pattern, you'll see no ghost. If you display the butterfly during 30 seconds, you see a light ghost. If you display the butterfly during 5 minutes, you see a strong ghost. And after 10 min, the ghosts fades away. I can't explain that behaviour with a digital phenomenon, it is an analogue one, in my opinion.

Personally, I would suspect a lack of refreshing of the LCD. If the LCD has shown the same image long enough, the liquid crystal keeps perhaps this image in a sort of memory effect, during about 10 min.

Yes, as you stated, VDD is connected to 1.8V on our board, and "BYPASS_REG1V8" is connected to 1.8V too. "VDDA1V8_DSI" is connected to the same 1.8V supply than VDD. Our device runs on a Li-Ion battery, we have designed it with as much 1.8V as possible.

OL'He.1
Associate III

Hello MM.1, thanks for your comment.

Yes, our device is in video mode. I am not sure to understand your question about layers. What are those layers? We can observe the ghosts even on the pattern generated by the Video Pattern Generator of the DSI host block, so as I understand the HW, the LTDC is not involved.

That's sound strange to me too, especially when I see that your display has no frame buffer.

I assume you checked the 2.8-3.3V supply of the LCD as well as keeping DSI rate below 550Mbps (If you use it in dual data lanes).

Maybe another test to completely exclude that ghost image is coming from LTDC could be to change the LTDC image (in DDR framebuffer, e.g. opening a console windows) while the DSI is kept in VPG mode. If the 'ghost' content (butterfly and tux) does not change, it is surely coming from the LCD itself which has memorized something.

You could also check if the phenomenom is temperature dependent ? If something linked to analog, should behave differently if 5C or 60C. You could even imagine changing temperature of the display only.

Regards.

In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.

Additional information from our experts is to check if burst mode is activated.

It requires adding MIPI_DSI_MODE_VIDEO_BURST in the flags of the panel driver.

Could you share your device tree (private message if contain sensitive information) ?

In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.