STM32U5A9 MIPI DSI Configuration Issue - Distorted Images / Timeout

[UKhan.2]

Hello ST Community,

I'm facing a MIPI DSI configuration issue with my STM32U5A9 and TFT LCD. When using PHY DSI as the DSI lane byte clock source, my code fails with a timeout on HAL_DSI_ShortWrite. When I switch to PLL3P, the initialization proceeds, but the LCD displays distorted images.

Request for Assistance: I'm new to MIPI and suspect a misconfiguration in clock settings. Any insights on proper configurations or similar experiences with STM32U5A9 MIPI DSI would be greatly appreciated.

Details:

• MCU: STM32U5A9
• LCD: TFT LCD with st7796S
• Clock Source: PHY DSI (fails) / PLL3P (distorted images)

 

 

Your help in resolving this challenge is appreciated. Share your insights or suggestions if you've encountered a similar problem.

Thank you,

[KDJEM.1]

Hello @UKhan.2 ,

Are you using DSI  ULPM mode? 

If it is the case, I advise you to take a look to DSI_ULPM_DataClock . In this example the DSI clock should be derived from the clock tree PLL3.PLLP (ck_plldsi) clock for instance to allow a switch-off of the PLL DPHY to save power during the ULPM phase.

More information about the clock configuration in README.md.

I hope this help you!

Kaouthar

 

 

[UKhan.2]

Yes, we are using DSI ULPM mode, and we started with the DSI_ULPM_DataClock example. We've adjusted the configurations for our 320×480 RGB888 display, following their suggested clock source (PLL3.PLLP). However, we're experiencing a distorted image on the screen, and the displayed colors don't match our intended ones when drawing shapes like rectangles. Any suggestions on resolving this issue?

[KDJEM.1]

Hi @UKhan.2 ,

Could you please refer to LTDC datasheet and check the timing configuration and the pixel clock configuration.

Note that the LTCD_CLK must be calculated using the parameters found in the display datasheet.

Please take a look to AN4861 and precisely 6 LTDC application examples section 6.

Thank you.

Kaouthar

[UKhan.2]

Dear Kaouthar,

Thank you for your response on the ST community forum. I appreciate the guidance you provided, and I have a few follow-up questions:

LTDC Clock Calculation:

In my current understanding, I am utilizing the following formula for FPS:

 

Fps = LCD_PCLK / ((LCD_WIDTH + LCD_HBP + LCD_HFP + LCD_HSW) * (LCD_HEIGHT + LCD_VBP + LCD_VFP + LCD_VSW))

 

Additionally, for MIPI configuration:

 

mipi_mbps = ((LCD_WIDTH + LCD_HBP + LCD_HFP + LCD_HSW) * (LCD_HEIGHT + LCD_VBP + LCD_VFP + LCD_VSW) * fps * 24) / MIPI_LANE

 

Might I be directed to the specific section in the LTDC datasheet where the relationship or formula connecting the display parameters for LTDC clock calculation is outlined? I can't seem to find that there.

PHY Timing Values:

I've included my current MIPI TFT display configurations for reference:

 

#define MIPI_LANE 1 // MIPI channel number selection, 1-4

#define LCD_WIDTH 320 // LCD width
#define LCD_HEIGHT 480 // LCD height

#define LCD_HBP 4 //Horizontal back porch
#define LCD_HFP 10 //Horizontal front porch
#define LCD_HSW 2 //Horizontal sync width

#define LCD_VBP 8 //Vertical back porch
#define LCD_VFP 6 //Vertical front porch
#define LCD_VSW 2 //vertical sync width

#define LCD_PCLK 10 //LCD PCLK clock setting, unit Mhz
#define LCD_PCLK_P0LARITY 0 //LCD PCLK clock polarity setting, 0=no inversion, 1=inversion
#define LCD_DE_P0LARITY 0 //DE polarity, 0=active low, 1=active high
#define LCD_HSYNC_P0LARITY 0 //HSYNC polarity, 0=low effective, 1=high effective
#define LCD_VSYNC_P0LARITY 0 //VSYNC polarity, 0=active low, 1=active high

 

In relation to the HS to LS and LP to HS timings, could you recommend specific values?

Uncertain about the necessity, I have an external oscillator operating at a frequency of 24.576MHz serving as the input frequency:

 

 

Any additional insights or specific recommendations you can provide would be immensely helpful.

Thank you for your continued support.

Best regards,

[Tesla DeLorean]

>>Any additional insights or specific recommendations you can provide would be immensely helpful.

Out-flow rate on DSI needs to EXCEED LTDC deliver rate. Just meeting might work, the porches give you some leeway.

If the colours and lines mess up, it's likely a frame buffer or geometry issue.

[KDJEM.1]

Hi @UKhan.2 ,

Thank you for this update.

Might I be directed to the specific section in the LTDC datasheet where the relationship or formula connecting the display parameters for LTDC clock calculation is outlined? I can't seem to find that there. 6.2.4 LTDC peripheral configuration Section  (Pixel clock configuration page 78)

Could you please take a look to AN4860 may be the 5. DSI host configuration Section and  6 STM32CubeMX configuration example Section. I think can help you to use DSI host. 

I hope this help you to solve the issue.

Thank you.

Kaouthar

[UKhan.2]

Thank you for your suggestion.

I'm reviewing AN4860, specifically the 5th DSI host configuration section and the 6th STM32CubeMX configuration example section.

 

I do have one question: Could you clarify whether the Pixel clock being set there :

is equivalent to the LTDC Clock in my case?

I'm unable to locate the pixel clock setup in my .ioc file.

Appreciate your assistance!

[UKhan.2]

Characters have been successfully displayed on the LCD; however, they appear inverted and mirrored. Assistance in identifying the underlying issue would be greatly appreciated.

Your guidance in this matter would be highly appreciated.

[MM..1]

First try

/**
 * @brief Start test pattern generation
 * @PAram hdsi pointer to a DSI_HandleTypeDef structure that contains
 * the configuration information for the DSI.
 * @PAram Mode Pattern generator mode
 * This parameter can be one of the following values:
 * 0 : Color bars (horizontal or vertical)
 * 1 : BER pattern (vertical only)
 * @PAram Orientation Pattern generator orientation
 * This parameter can be one of the following values:
 * 0 : Vertical color bars
 * 1 : Horizontal color bars
 * @retval HAL status
 */
HAL_StatusTypeDef HAL_DSI_PatternGeneratorStart(DSI_HandleTypeDef *hdsi, uint32_t Mode, uint32_t Orientation)

after this work next step is framebuffer setup...

[UKhan.2]

Dumping the framebuffer and displaying it on GIMP confirms that the transmitted framebuffer is accurate, but there seems to be a misinterpretation by the Display controller.

I've attempted various configurations on the controller's side to address the issue, but the text continues to display as mirrored.

Alternating the MX bit in the this register, had not impact on the outcome - Any ideas would be much appreciated!

[chroniclestories]

Same Issue and after everything I didn't find any proper solution to this.