DSI Video Mode on STM32L4R9AI-EVAL using GFXMMU_Lut

[rgree.1]

I have successfully adapted a 480x480 round LCD to attach to the STM32L4R9AI-EVAL kit and can display an RGB888 image continuously, with a custom GFXMMU_Lut that reduces the required frame buffer to 558,336 bytes, and the frame buffer located in SRAM. I am now trying to use TouchGFX to start GUI development, the code built by TouchGFX Generator seems to target Adapted Command mode, I have been able to modify the CubeMX .ioc file and build the project. I cannot seem to get the TouchGFX code to properly display an image. I utilized the same image I displayed in the non TouchGFX code, and I can see that it is correct in the .cpp file and in the debugger. If I comment out the call to MX_TouchGFX_Init(); and follow it with a CopyInVirtualBuffer((uint32_t *)image_offset, (uint32_t *)GFXMMU_VIRTUAL_BUFFER0_BASE, 0, 0, 480, 480); call the image gets displayed properly, if I allow MX_TouchGFX_Init() to run it does not. Looking for ideas about what the TouchGFX initialization may be doing to change the configuration done in main.c so that the image transfer gets corrupted. Also curious if there is any reason TouchGFX might not work in Video Mode with the ChromART-GRC function enabled.

[rgree.1]

Have a possible answer to my own question, the MX_TouchGFX_Init() is changing my hdma2d instance of type DMA2D_HandleTypeDef, once I figure out whats wrong likely in my CubeMX ioc file TouchGFX generation will hopefully integrate properly.

[rgree.1]

The order of MX_TouchGFX_Init() and MX_DMA2D_Init() needed to be swapped. DMA2D configuration gets destroyed when MX_TouchGFX_Init() calls TouchGFXGeneratedHAL::initialize() and HAL:initialize located in HAL.hpp creates a new DMA2D instance.

[rgree.1]

I can confirm that with proper configuration the MIPI-DSI link in video mode works properly with TouchGFX and GFXMMU_Lut ChromART-GRC round display optimization enabled. The key is to understand the relationship between the GFXMMU Virtual Buffer and the physical frame buffer memory in RAM. The GRC optimization allows a 373,696 byte frame buffer in RGB565 format when using a round 480x480 pixel LCD. Proper initialization of the LCD controller ST7701S is critical to getting the LCD to function properly, and using Video Burst Mode is the best option with no internal graphic memory on the LCD module. If anyone has any tips on increasing the TouchGFX MainView::handleTickEvent() rate to allow faster GUI widget updates I would appreciate the feedback.