Question about wrong behavior at TouchGFX

[Jkim.6]

Hi st community members,

I'm having trouble when I'm porting DSI display and also integrating it into TouchGFX framework. Please let me know if you can point me out some clues about this.

1. First, I started to do porting the DSI display(24bit color), by just setting a framebuffer connected to a buffer in internal SRAM(global array). It was finally succeeded as below, the content is RGB pattern what I generated by couple of for loops to fill the framebuffers.

In this case, I didn't activated TouchGFX(MX_TouchGFX_Init).

2. As I saw successful porting of my DSI display, I started to activate TouchGFX framework

- activated MX_TouchGFX_Init and relevant codes.

- setup TouchGFX configuration in ioc file of STM32CubeIDE tool

- declared framebuffer as buffer allocation and set it also as LTDC framebuffer, by externing the array in main.c file

But what I see in this case is, something wrong.

- My display doesn't show the buffer correctly.

- It seems like it is something stretched than it's original size.

- It seems like one black(or empty) line is inserted every line after one red line.

Is there anyone who has this kind of experience before?

I don't really know where to start my debugging in this kind of situation.

For your information, let me add my relevant configuration as below.

<TouchGFX configuration in ioc file>

<MX_LTDC_INIT() function in main.c file>

<TouchGFXGeneratedHAL.cpp file - for buffer declaration point>

 

Thanks in advance.

[Mon2]

A suggestion while waiting for other replies is to run TouchGFX first -> select one of the ST kits which feature a native MIPI DSI port and display. Create a quick GUI -> simulate that it works ok. A simple touch button or similar should be ok.

Then proceed to import this finished project into the STM32CubeMX tools. If all goes well, the compiled STM32CubeMX project (that was imported) should continue to work on the selected kit.

Then review the details of this source code and configurations.

There is a lot that can break and a single issue can consume days / weeks of debugging time. Been there.

Share more details on the kit you have. Are you using a STM32 processor with MIPI on the CPU?

We will be heavy into similar research very soon but our plans are to use the Solomon parallel to MIPI bridge for a number of reasons. This way, we can make use of STM32 wizard generated code that will perform 99% of our required homework. Much easier to deploy in our opinion.

[Jkim.6]

Thanks for your reply, Mon2. I agree with your suggestion and will check it one by one as you suggested.

I am developing custom board kit based on STM32L4R9ZI processor. It has MIPI on the CPU, of course.

We actually started our work from STM32L4R9I EVAL board from ST's, and it also worked correctly with its built-in round type display.

[MM..1]

I see primary trouble , that you set Custom drivers. When you use DSI with full framebuffer, you need set LTDC not Custom.

[Jkim.6]

Thanks for your experienced reply, MM..1.

Actually it was the point I didn't consider at all before.

I will try to change the Display Interface from Custom to Parallel RGB(LTDC) as you suggested, and let you know about the result.

​

[Jkim.6]

For whom who will need this information later, let me update on this.

I finally needed two changes to correctly display my TouchGFX resources.

1. Set Display Interface from Custom to Parallel RGB(LTDC) as MM..1 mentioned.(Thanks again MM..1 for mentioning it ! )
2. Set Correct Framebuffer Width in TouchGFXHAL.cpp file.

As I was using the original version from ​STM32L4R9I EVAL board, it was defined based on GFXMMU dependent buffer width(3072/2).

The definition goes like BSP_LCD_IMAGE_WIDTH -> GUI_FRAME_BUFFER_WIDTH -> FRAME_BUFFER_WIDTH, finally.

After correcting the width as the one considering DMA2D transfer width, I can see outputs from TouchGFX delivered by DMA2D finally.

[Romain DIELEMAN]

Great to hear that it works :thumbs_up:, it is true that the L4R9 eval application template has a different approach due to the round display I did not think of that.

​

/Romain