2021-05-03 10:21 AM
Hi,
I finished the board bring up introduction: Board Bring Up Introduction | TouchGFX Documentation without any troubles.
I can also write and read to the external flash through DMA2D by using the following function:
LL_FillBuffer(LTDC_LAYER_1, (uint32_t *)(hltdc.LayerCfg[LTDC_LAYER_1].FBStartAdress), 1024, 600, 0, (uint32_t) 0xFF008000);
static void LL_FillBuffer(uint32_t LayerIndex, void *pDst, uint32_t xSize, uint32_t ySize, uint32_t OffLine, uint32_t ColorIndex)
{
/* Register to memory mode with RGB8888 as color Mode */
hdma2d.Init.Mode = DMA2D_R2M;
hdma2d.Init.ColorMode = DMA2D_OUTPUT_RGB888;
hdma2d.Init.OutputOffset = OffLine;
hdma2d.Instance = DMA2D;
/* DMA2D Initialization */
if(HAL_DMA2D_Init(&hdma2d) == HAL_OK)
{
if(HAL_DMA2D_ConfigLayer(&hdma2d, LayerIndex) == HAL_OK)
{
if (HAL_DMA2D_Start(&hdma2d, ColorIndex, (uint32_t)pDst, xSize, ySize) == HAL_OK)
{
/* Polling For DMA transfer */
HAL_DMA2D_PollForTransfer(&hdma2d, 10);
}
}
}
}
The external RAM is then transferred though MIPI DSI and shown as expected:
However if I enable TouchGFX through Cube MX and it write to the framebuffer I do get some strange display issues on the screen:
I am working in RGB888 mode and a screen with 1024x600.
Does someone have any idea why the image is not written correctly in the framebuffer by TouchGFX. Or do I have some other timing or formatting issues?
Kind Regards
Solved! Go to Solution.
2021-05-05 12:41 AM
Hi All,
So I found the setting that caused the troubles with the pixel shift. I used the STM32F769i TouchGFX generated example code to my hardware. Unfortunately there is a hardcoded pixel adaption in the generated code:
TouchGFXHAL::TouchGFXHAL(touchgfx::DMA_Interface& dma, touchgfx::LCD& display, touchgfx::TouchController& tc, uint16_t width, uint16_t height)
/* USER CODE BEGIN TouchGFXHAL Constructor */
: TouchGFXGeneratedHAL(dma,
display,
tc,
width + 32, /* Align to match 832 pixel for optimal DSI transfer */
height)
/* USER CODE END TouchGFXHAL Constructor */
{
/* USER CODE BEGIN TouchGFXHAL Constructor Code */
/* USER CODE END TouchGFXHAL Constructor Code */
}
There is an adaption to the initial resolution of with+32. This of course causes troubles if the resolution is adapted! So remove this and everything should be fine.
2021-05-03 12:28 PM
Seems as your config is in bad orientation try 90 angle or check if display is real 1024x600 or 600x1024
2021-05-03 11:43 PM
Hi, Thanks for the fast reply. I tried some different configuration with the angle but no luck. I dont get why I can draw correctly to the framebuffer though dma2d but touchgfx cant. It seems to mix the last screen with the current and also draws it in a really strange manner. Some other configuration that could lead to this error?
2021-05-04 02:02 AM
As first fill buffer with one color is very bad test. As second TouchGFX draw to buffer too, result is your image.
Basic tachgfx is only memory manager , create graphics in memory in defined condition.
Trafic from memory to LCD is different think, and is based on very big configs and possible mistakes. As i write before you need know and setup this hw part.
2021-05-04 05:52 AM
Hi,
Ok I implemented a better test. I am now drawing the image generated by TouchGFX (RGB888) by DMA2D to the framebuffer at position 0,0. The image is copied to the buffer and from there through LTDC and MIPI DSI to the screen:
That prooves that the drivers work and all timing is correct:
Now If I create a screen in TouchGFX and put the same image in the screen and let TouchGFX draw the image to the framebuffer it looks like this:
So it must be some kind of configuration in CubeMX or TouchGFX but I really dont know what could be wrong. Any Idea?
2021-05-04 06:52 AM
Update: When I compare the memory I the first 3000 bytes are correct in both cases, but then the TouchGFX version starts to differ from the original image and bytes start to be different from the original. Is there some kind of image processing or race condition that could cause this kind of behaviour?
2021-05-04 07:10 AM
I did another test to clarify:
I set up a black white screen in touchGFX:
Running the program produces this frame:
So its not really image processing, its some kind of configuration that is totally wrong, but I dont get what it could be. Some help would be really appreciated!
2021-05-04 07:35 AM
As i write on start your display is maybe wrong oriented and test with
if (HAL_DMA2D_Start(&hdma2d, ColorIndex, (uint32_t)pDst, xSize, ySize) == HAL_OK)
dont check this because xsize and ysize only define how many pixels transfer and is simply equal to ysize,xsize
too i dont understand how you test and activate touchgfx.
Good is use full generated code cubeMX with touch, then comment out start OS and insert your fill test image before main while.
2021-05-04 09:17 AM
Yes I do use a fully generated CubeMX Project with TouchGFX enabled under Software Packs. I also do exactly what you propose and draw the image out before the activate touchgfx gets called.
I do have another interesting observaition: I've put two lines of 32 pixel of the color green on the right side in TouchGFX. The second line is then not shown on the right but at the very beginning of the second line. So theres some kind of shift for each line written to the framebuffer. That explains why the image is shown this way. You have to look at the first two pixel lines in the image:
2021-05-05 12:41 AM
Hi All,
So I found the setting that caused the troubles with the pixel shift. I used the STM32F769i TouchGFX generated example code to my hardware. Unfortunately there is a hardcoded pixel adaption in the generated code:
TouchGFXHAL::TouchGFXHAL(touchgfx::DMA_Interface& dma, touchgfx::LCD& display, touchgfx::TouchController& tc, uint16_t width, uint16_t height)
/* USER CODE BEGIN TouchGFXHAL Constructor */
: TouchGFXGeneratedHAL(dma,
display,
tc,
width + 32, /* Align to match 832 pixel for optimal DSI transfer */
height)
/* USER CODE END TouchGFXHAL Constructor */
{
/* USER CODE BEGIN TouchGFXHAL Constructor Code */
/* USER CODE END TouchGFXHAL Constructor Code */
}
There is an adaption to the initial resolution of with+32. This of course causes troubles if the resolution is adapted! So remove this and everything should be fine.