RGB666

[Cclad.1]

Hi,

I am using stm32h753vi 100pin package.

I have it set up with touchgfx, and am getting output on my lcd (Raystar RFS520A-AZH-DNG 128x480).

I chose this stm32 as space is quite limited, and I don't need RGB888 (I don't think).

I have connected it as RGB666, and tied the 2 lsb lines of the RGB to gnd.

My problem is that the red and blue colours are not coming out as expected.

When I display a green gradient all is fine

But when I display a red or blue gradient I have severe banding

I have LTDC display type set to RGB666 and everything else set to RBG888. I have been through all my pin designations, and connections on the circuit to make sure I have no shorts, or bad connections. I have also checked all lines at the lcd with my oscilloscope and there is data on all of the RGB666 lines.

Here is the dma and ltdc code generated by the configuration tool.

static void MX_DMA2D_Init(void)
{
 
  /* USER CODE BEGIN DMA2D_Init 0 */
 
  /* USER CODE END DMA2D_Init 0 */
 
  /* USER CODE BEGIN DMA2D_Init 1 */
 
  /* USER CODE END DMA2D_Init 1 */
  hdma2d.Instance = DMA2D;
  hdma2d.Init.Mode = DMA2D_M2M;
  hdma2d.Init.ColorMode = DMA2D_OUTPUT_RGB888;
  hdma2d.Init.OutputOffset = 0;
  hdma2d.LayerCfg[1].InputOffset = 0;
  hdma2d.LayerCfg[1].InputColorMode = DMA2D_INPUT_RGB888;
  hdma2d.LayerCfg[1].AlphaMode = DMA2D_NO_MODIF_ALPHA;
  hdma2d.LayerCfg[1].InputAlpha = 0;
  hdma2d.LayerCfg[1].AlphaInverted = DMA2D_REGULAR_ALPHA;
  hdma2d.LayerCfg[1].RedBlueSwap = DMA2D_RB_REGULAR;
  hdma2d.LayerCfg[1].ChromaSubSampling = DMA2D_NO_CSS;
  if (HAL_DMA2D_Init(&hdma2d) != HAL_OK)
  {
    Error_Handler();
  }
  if (HAL_DMA2D_ConfigLayer(&hdma2d, 1) != HAL_OK)
  {
    Error_Handler();
  }
  /* USER CODE BEGIN DMA2D_Init 2 */
 
  /* USER CODE END DMA2D_Init 2 */
 
}

static void MX_LTDC_Init(void)
{
 
  /* USER CODE BEGIN LTDC_Init 0 */
 
  /* USER CODE END LTDC_Init 0 */
 
  LTDC_LayerCfgTypeDef pLayerCfg = {0};
 
  /* USER CODE BEGIN LTDC_Init 1 */
 
  /* USER CODE END LTDC_Init 1 */
  hltdc.Instance = LTDC;
  hltdc.Init.HSPolarity = LTDC_HSPOLARITY_AL;
  hltdc.Init.VSPolarity = LTDC_VSPOLARITY_AL;
  hltdc.Init.DEPolarity = LTDC_DEPOLARITY_AL;
  hltdc.Init.PCPolarity = LTDC_PCPOLARITY_IPC;
  hltdc.Init.HorizontalSync = 0;
  hltdc.Init.VerticalSync = 1;
  hltdc.Init.AccumulatedHBP = 43;
  hltdc.Init.AccumulatedVBP = 84;
  hltdc.Init.AccumulatedActiveW = 523;
  hltdc.Init.AccumulatedActiveH = 212;
  hltdc.Init.TotalWidth = 531;
  hltdc.Init.TotalHeigh = 290;
  hltdc.Init.Backcolor.Blue = 0;
  hltdc.Init.Backcolor.Green = 0;
  hltdc.Init.Backcolor.Red = 0;
  if (HAL_LTDC_Init(&hltdc) != HAL_OK)
  {
    Error_Handler();
  }
  pLayerCfg.WindowX0 = 0;
  pLayerCfg.WindowX1 = 480;
  pLayerCfg.WindowY0 = 0;
  pLayerCfg.WindowY1 = 128;
  pLayerCfg.PixelFormat = LTDC_PIXEL_FORMAT_RGB888;
  pLayerCfg.Alpha = 255;
  pLayerCfg.Alpha0 = 0;
  pLayerCfg.BlendingFactor1 = LTDC_BLENDING_FACTOR1_PAxCA;
  pLayerCfg.BlendingFactor2 = LTDC_BLENDING_FACTOR2_PAxCA;
  pLayerCfg.FBStartAdress = 0;
  pLayerCfg.ImageWidth = 480;
  pLayerCfg.ImageHeight = 128;
  pLayerCfg.Backcolor.Blue = 0;
  pLayerCfg.Backcolor.Green = 0;
  pLayerCfg.Backcolor.Red = 0;
  if (HAL_LTDC_ConfigLayer(&hltdc, &pLayerCfg, 0) != HAL_OK)
  {
    Error_Handler();
  }
  /* USER CODE BEGIN LTDC_Init 2 */
 
  /* USER CODE END LTDC_Init 2 */
 
}

I wonder if anyone has any suggestions as to where I should look for the fault?

Many thanks

[MM..1]

How you create gradients and ho wsetup use TouchGFX RGBxxx? When this is 16bit and png images , then corruption is on convert phase not on your lcd.

[Cclad.1]

Hi MM and thanks for your reply.

The gradients are png files from photoshop.

I am using the device configuration tool in CubeIDE using these settings:

 

And in touchgfx:

So I think I have it set to RGB666 on the LTDC, and RGB888 everywhere esle.

As I understand it this means that my images are saved in RGB888 and then when put out to the display the bottom 2 bits of the RGB lines are dropped making RGB666. Is this correct?

So I don't think it is a conversion issue, but please correct me if I am wrong.

[MM..1]

Seems config is OK then trouble maybe is your PCB quality or simply use gradient to white isnt good idea. This use all combinations RGB and isnt good for LCD with 565 or 666 . Try check gradients to black with clear red and blue.

[Cclad.1]

Thanks so much for taking the time to answer MM.

Your suggestion of trying the gradients to black has helped me solve the problem.

For anyone else who might have similar problems in the future I will explain:

With my initial tests above the red and blue gradients to white were exhibiting the problem so I focused on these lines to find the problem.

When I tried gradients to black it was only the green gradient which exhibited the problem, and it was the green component of the white which was causing the problems in the above images. So a bit more testing on the circuit board found a dodgy connection on G5 (which I must have pushed together with my multimeter when I first checked it).

Re-soldering this has solved it and I now have good colours.

Shows how a small problem can be a real time waster!

Thanks again

[royih28087]

Hi, can you please share the part of your schematic where you route pins from STM32 to a connector/display?

Your lqfp-100 STM32 doesn't have LCD_R0, so on that fact alone, you can't use data transfer in RGB888 color format.

Also, isn't RGB565 is the best option here?

I wonder how you connected RGB lines from MCU to display, is it like MCU -> Display, R1 -> R1

For RGB565 there seems to be a particular way to connect MCU RGB lines to Display RGB lines.

[MM..1]

Read carefully first post, from MCU RGB666 is R2-R8 ... connected to LCD

R0 R1 on lcd is on gnd ofcourse too G0 G1 B0 B1

And your question for better image quality is RGB666 ok, but more memory required because framebuffer must be RGB888. Then for simple designs RGB565 is more effective.

[royih28087]

I wish you'd show schematic, wouldn't even need to describe anything, just upload it and that's it.

What you said, unfortunately, doesn't help me understand at all.

I know first two R0 and R1 go to GND in RGB666, but how are the connections made to a 40pos connector from STM32??? Nobody ever shows this.

Let me use specific chips, for clear understanding.

Example #1

RGB888, 24-bit RGB parallel interface connections - it's easy to understand how to make connections from STM32 to 40-pos FPC connector.

Assume you have STM32H753BIT6 which is in LQFP-208 package, so all the necessary 8 pins for each of the RGB data lines are present.

40pos connector in 24-bit RGB parallel interface, has #5 pin go to LCD_R0 on STM32 side (pad #46, PH2)

An external display such as this (has a good datasheet compared to many other external displays) connects to pin #5 of this FPC connector with R0 on Display side, based on OTA5180A LCD display driver, the relevant pads on this IC are #140,141 "DR0".

For 24-bit RGB parallel interface, all is understandable, makes sense.

The names "R[0:7], G[0:7], B[0:7]" match between STM32 and TFT LCD Display module, so there's no confusion how each of them connects to this 40-pos connector.

---

I don't get how connections are made from STM32 to female/receptacle 40-pos FPC connector in RGB565 (or RGB666 in your case). When I try to configure with CubeMX it only shows either RGB888 or RGB565 modes.

And what's the convention of connections made from TFT LCD Displays to their male ribbon 40-pos cable in RGB565 mode? Do all manufacturers follow the same convention?

Example #2

Assume you have same STM32 but in LQFP-100 package (LCD_R0/PH2 is missing), but the same display module as in Example #1.

So you want to make compatible connection from this STM32 in RGB565 mode. Even though Display expects RGB888, it would still work with STM32, if (LSB) 3 bits from R, 2 bits from G, 2 bits from B are ignored.

Now, the display module with its ribbon 40-pos cable would connect the same, meaning its R0 data line would still go to pin #5 of receptacle FPC 40-pos connector.

So in this case, does one simply connect pin #5 of FPC connector to GND?

Then the pin #6 and pin #7 also tie to GND? Which pin from STM32 will go to pin #8 of FPC connector?

Is it pin with the function LCD_R3 (PB0)? So basically, same connection as in RGB 24-bit parallel interface, but without missing RGB data lines?

If yes, what about external TFT LCD displays that only support 16-bit RGB interface? Would this connection with FPC connector be appropriate with them? Like does their Red LSB bit will go to pin #5 of FPC connector or to pin #8 of FPC connector? This is my most important question I guess.

Also, when I look at datasheets of TFT LCD displays that only support 16-bit RGB interface, they don't show clearly how the RGB data lines are arranged on a 55 pin cable, or if there's a 40pos cable compatible with 40pos FPC connector, its pin arrangement wildly differs from what I wrote above.

For instance, pins #5 to #13 are all GND. And the ordering is reverse, B0 is at pin #18. See here.

Another 16-bit RGB display, the order on its 40pos cable is also too different, see here on p.4

Here's another one with 45-pos cable, but it shows R0 connection towards MCU, which I don't have in lqfp-100? Or am I reading too much into "R0" and assume they mean PH2 pin, when in fact it's LSB bit on red data line, which can be LCD_R3 (PB0)?

Or in regards to RGB565 mode, should STM32 to FPC connection be per this schematic:

In which, LCD_R5 pin (PA12) goes to pin #5 of FPC connector and to pin #10 of FPC connector? Is it done for better brightness or something? Why not just pull pins #5-7 of FPC connector high then? Doesn't make quite sense to me.

[MM..1]

  100pin STM in MX

You need diferentiate :

Pinout MODE : RGBxxx  how is connected pins stm to lcd

Pixel memory modes for framebuffer and for stored images

 here you never see 666 ...

all this is valid for video mode displays. And for your question every manufactureer have own conn, you create your design for your display. Unused pins from colors is good connect to gnd or for beter white as on your last schematics. Your idea connect to high will result to never black display.