DSI display not init always OK

[MM..1]

Hi folks,

i use CubeMX and touchGFX generated code with custom DSI 480x1280 display.

All code works ok , but sometimes display is shifted horizontaly.

70% starts code on and display is pixel 0 to 479 ok.

But 30% starts dispolay randomly shifted and show 60-479-0-59 and rgb is too shifted randomly to gbr or brg. 60 is too random between 30 - 150

I need idea howto solve this.

We use FMC SDRAM and seems as LTDC DSI sync data problem.

Pls help. I attach hwinit cpp file. MCU in main is started and go to sleep

HAL_PWR_EnterSTOPMode(PWR_LOWPOWERREGULATOR_ON, PWR_STOPENTRY_WFI);

then wake up by button and go. Code work all ok only GUI is sometimes shifted.

[Tesla DeLorean]

Do you send any configuration to the display side controller? Sync and porch timing type stuff?

Not going to unpack code for hardware I don't have.

You should be able to validate the functionality of the SDRAM locally. Soak test, and do reset tests to confirm it functions, so you can be confident it is not the source of any issues.

Does your design have a proper POR circuit? Does the display/controller have an async reset? Is is wired to the POR?

[MM..1]

Hi Clive,

of course we send init over LP DSI and display allways work.

Special POR we dont have , use internal STM32F469 POR and display have reset line used before init.

Next info in cycle ON OFF device 3,3V isnt off and is alltime present. Off sw use watchdog reset stm.

[MM..1]

I have news and images,

maybe anybody have same issue.

Same code turened ON ok.

Same code next turn ON bad

I check memory and data is ok in mem position. Too i place one test point to left down corner after init display before start touchGFX rtos

and point is showed always properly and shifted after touch graphics make first show from black disp with only one point in corner.

Then i add to one button control code to start HAL_DSI_PatternGeneratorStart(&hdsi, 0, 0); Next press stop and miracle bad is corrected to ok.

Please help?

[MM..1]

I found solution , this bug exist with TouchGFX 4.12.3,

but is solved in 4.13.0 Designer libs.

EDIT: More testing and problem is back...

[MM..1]

Have anybody this problem? Maybe clock config is source ?

void SystemClock_Config(void)

{

 RCC_OscInitTypeDef RCC_OscInitStruct = {0};

 RCC_ClkInitTypeDef RCC_ClkInitStruct = {0};

 RCC_PeriphCLKInitTypeDef PeriphClkInitStruct = {0};

 /** Configure the main internal regulator output voltage 

 */

 __HAL_RCC_PWR_CLK_ENABLE();

 __HAL_PWR_VOLTAGESCALING_CONFIG(PWR_REGULATOR_VOLTAGE_SCALE1);

 /** Initializes the CPU, AHB and APB busses clocks 

 */

 RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_LSI|RCC_OSCILLATORTYPE_HSE;

 RCC_OscInitStruct.HSEState = RCC_HSE_ON;

 RCC_OscInitStruct.LSIState = RCC_LSI_ON;

 RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;

 RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSE;

 RCC_OscInitStruct.PLL.PLLM = 4;

 RCC_OscInitStruct.PLL.PLLN = 180;

 RCC_OscInitStruct.PLL.PLLP = RCC_PLLP_DIV2;

 RCC_OscInitStruct.PLL.PLLQ = 4;

 RCC_OscInitStruct.PLL.PLLR = 2;

 if (HAL_RCC_OscConfig(&RCC_OscInitStruct) != HAL_OK)

 {

  Error_Handler();

 }

 /** Activate the Over-Drive mode 

 */

 if (HAL_PWREx_EnableOverDrive() != HAL_OK)

 {

  Error_Handler();

 }

 /** Initializes the CPU, AHB and APB busses clocks 

 */

 RCC_ClkInitStruct.ClockType = RCC_CLOCKTYPE_HCLK|RCC_CLOCKTYPE_SYSCLK

               |RCC_CLOCKTYPE_PCLK1|RCC_CLOCKTYPE_PCLK2;

 RCC_ClkInitStruct.SYSCLKSource = RCC_SYSCLKSOURCE_PLLCLK;

 RCC_ClkInitStruct.AHBCLKDivider = RCC_SYSCLK_DIV1;

 RCC_ClkInitStruct.APB1CLKDivider = RCC_HCLK_DIV4;

 RCC_ClkInitStruct.APB2CLKDivider = RCC_HCLK_DIV2;

 if (HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_5) != HAL_OK)

 {

  Error_Handler();

 }

 PeriphClkInitStruct.PeriphClockSelection = RCC_PERIPHCLK_LTDC;

 PeriphClkInitStruct.PLLSAI.PLLSAIN = 60;

 PeriphClkInitStruct.PLLSAI.PLLSAIR = 3;

 PeriphClkInitStruct.PLLSAIDivR = RCC_PLLSAIDIVR_2;

 if (HAL_RCCEx_PeriphCLKConfig(&PeriphClkInitStruct) != HAL_OK)

 {

  Error_Handler();

 }

}

[TTulw.1]

I have the same problem. The whole screen is shifted to the right by random amount of pixels. It only happens when I reset the device with taking power off or reset pin.

When I software reset after reprograming the shift never occurs. I use TouchGFX 4.15.

I've tried many porch, sync and pixel clock settings.

Reseting the peripherals (ram, LCD, QSPI) doesn't solve the shift.

[MM..1]

I now use workaround with twice call

if (HAL_DSI_ConfigVideoMode(&hdsi, &VidCfg) != HAL_OK)

 {

  Error_Handler();

 }

one on init dsi and second after around 500ms later.

But still i see very undocumented startup DSI on STM32.

[TTulw.1]

Tried it but same issue. My  HAL_DSI_ConfigVideoMode configuration:

hdsivideo_handle.VirtualChannelID = LCD_OTM8009A_ID;

 hdsivideo_handle.ColorCoding = DSI_RGB565 ;

 hdsivideo_handle.VSPolarity = DSI_VSYNC_ACTIVE_HIGH;

 hdsivideo_handle.HSPolarity = DSI_HSYNC_ACTIVE_HIGH;

 hdsivideo_handle.DEPolarity = DSI_DATA_ENABLE_ACTIVE_HIGH;  

 hdsivideo_handle.Mode = DSI_VID_MODE_BURST /* Mode Video burst ie : one LgP per line */

 hdsivideo_handle.NullPacketSize = 0xFFF;

 hdsivideo_handle.NumberOfChunks = 0;

 hdsivideo_handle.PacketSize        = HACT; /* Value depending on display orientation choice portrait/landscape */

 hdsivideo_handle.HorizontalSyncActive   = (HSA * laneByteClk_kHz) / LcdClock;

 hdsivideo_handle.HorizontalBackPorch    = (HBP * laneByteClk_kHz) / LcdClock;

 hdsivideo_handle.HorizontalLine      = ((HACT + HSA + HBP + HFP) * laneByteClk_kHz) / LcdClock; /* Value depending on display orientation choice portrait/landscape */

 hdsivideo_handle.VerticalSyncActive    = VSA;

 hdsivideo_handle.VerticalBackPorch     = VBP;

 hdsivideo_handle.VerticalFrontPorch    = VFP;

 hdsivideo_handle.VerticalActive      = VACT; /* Value depending on display orientation choice portrait/landscape */

 /* Enable or disable sending LP command while streaming is active in video mode */

 hdsivideo_handle.LPCommandEnable = DSI_LP_COMMAND_ENABLE; /* Enable sending commands in mode LP (Low Power) */

 /* Largest packet size possible to transmit in LP mode in VSA, VBP, VFP regions */

 /* Only useful when sending LP packets is allowed while streaming is active in video mode */

 hdsivideo_handle.LPLargestPacketSize = 16;

 /* Largest packet size possible to transmit in LP mode in HFP region during VACT period */

 /* Only useful when sending LP packets is allowed while streaming is active in video mode */

 hdsivideo_handle.LPVACTLargestPacketSize = 0;

 /* Specify for each region of the video frame, if the transmission of command in LP mode is allowed in this region */

 /* while streaming is active in video mode                                     */

 hdsivideo_handle.LPHorizontalFrontPorchEnable = DSI_LP_HFP_ENABLE;  /* Allow sending LP commands during HFP period */

 hdsivideo_handle.LPHorizontalBackPorchEnable = DSI_LP_HBP_ENABLE;  /* Allow sending LP commands during HBP period */

 hdsivideo_handle.LPVerticalActiveEnable = DSI_LP_VACT_ENABLE; /* Allow sending LP commands during VACT period */

 hdsivideo_handle.LPVerticalFrontPorchEnable = DSI_LP_VFP_ENABLE;  /* Allow sending LP commands during VFP period */

 hdsivideo_handle.LPVerticalBackPorchEnable = DSI_LP_VBP_ENABLE;  /* Allow sending LP commands during VBP period */

 hdsivideo_handle.LPVerticalSyncActiveEnable = DSI_LP_VSYNC_ENABLE; /* Allow sending LP commands during VSync = VSA period */

[TTulw.1]

I tried changing the HorizontalSyncActive parameter and it worked!

I just divided the calculated value by 2:

 hdsivideo_handle.HorizontalSyncActive   = (HSA * laneByteClk_kHz) / LcdClock / 2;

It seems that the sync pulse wasn't recognised, changing it to smaller value worked. Can someone clarify what are exact formulas to calculate those parameters ?

For me the the paramteres are:

HSA=25

laneByteClk_kHz = 62500

LcdClock = 43200