Skip to main content
Visitor II
June 5, 2020
Question

Problem with MIPI DSI on STM32MP157C CAD package?

  • June 5, 2020
  • 8 replies
  • 4842 views

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>
    This topic has been closed for replies.

    8 replies

    Technical Moderator
    June 5, 2020

    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,

    OL'He.1Author
    Visitor II
    June 5, 2020

    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.1Author
    Visitor II
    July 24, 2020

    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.

    Technical Moderator
    July 28, 2020

    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 ?

    Graduate II
    July 28, 2020

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

    OL'He.1Author
    Visitor II
    July 29, 2020

    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.

    Technical Moderator
    July 30, 2020

    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.

    OL'He.1Author
    Visitor II
    August 5, 2020

    PatrickF, you wrote: "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)."

    We have already checked the VCC and IOVCC supplies of our screen, they are at 2.8V and 1.8V respectively, and free of noise. We'll check it again.

    I was not aware of a limitation of the DSI rate to 550 Mbps. Do you mean 550 Mbps per lane, or for the full DSI? Could you point me to the documentation that explains this limitation?

    I have tried to lower the frame rate to 50 Hz, which brings the data rate to the same value as the Orise Tech LCD of the DK2. It does not change anything to the artefacts I see, with or without "MIPI_DSI_MODE_VIDEO_BURST".

    Thanks!

    OL'He.1Author
    Visitor II
    July 29, 2020

    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.

    Graduate II
    July 30, 2020

    Hi, your images show as over pattern generator is alpha blended next layer. As in LTDC . Too i mean multicore as this MP can connect DSI to Cortex4 but too to Cortex7 and here can start trouble as this. Good is message from PatrickF to test show any change on display in sw when pattern is active.

    Too try stop LTDC before start HAL_DSI_PatternGeneratorStart(&hdsi, 0, 1);

    OL'He.1Author
    Visitor II
    July 30, 2020

    Hello MM.1.

    Thanks for your interest.

    At first sight, it looks like an alpha blending indeed. However, I think I have ruled out alpha blending because:

    1. The ghost effect clearly depends on the time during which the previous ghost image is displayed on the LCD. If displayed 2 seconds, no ghost, if displayed 5 minutes, strong ghosts. An alpha blending could not behave like that, AFAIK.
    2. We see the ghosts even when displaying the pattern from the hardware Video Pattern Generator, which completely shortcut the LTDC.

    BTW, we do not use the Cortex-M4 at all. It is neither programmed nor started.

    OL'He.1Author
    Visitor II
    July 30, 2020

    PatrickF, we do not use "MIPI_DSI_MODE_VIDEO_BURST" yet, only "MIPI_DSI_MODE_VIDEO".

    I have just seen the driver of the DK2's Orise Tech otm8009a LCD does use "MIPI_DSI_MODE_VIDEO_BURST" and "MIPI_DSI_MODE_LPM".

    I'll try with those flags and share the device tree in a private message.

    Thanks for the hint!

    OL'He.1Author
    Visitor II
    July 30, 2020

    I have added the "MIPI_DSI_MODE_VIDEO_BURST" flag to the current "MIPI_DSI_MODE_VIDEO". No difference, we have the same artefacts.

    I have added "MIPI_DSI_MODE_LPM" as well, then I see nothing on the screen.

    (My tests were a bit naive, just adding the flags in the driver, no time to check they were taken into account.)

    Graduate II
    August 6, 2020

    You use low limit VCI 2.8V , try go up or use other power source

    OL'He.1Author
    Visitor II
    August 7, 2020

    Hello MM.1 and PatrickF.

    Thanks for your suggestion. We had already raised the VCI limit to 3.0V and 3.3V without improvements on our artefacts, but we had done it using the STPMIC1 on our custom board.

    Yesterday, we have physically connected both the VCI and the IOVCC supplies of our LCD display to a lab power supply, and all LCD artefacts disappeared. :)

    It was not a question of raising the voltage, the lab supply voltages were the same. When we reconnected the LCD's VCI and IOVCC supplies to the outputs of our STPMIC's BUCK4 and BUCK3 respectively, instead of LDO1 and LDO6, the LCD display showed almost perfect images, without any artefact.

    We still need to understand this LDO limitation, but we have progressed a lot and know the problem is in the LCD supplies.

    Thanks for your support!