modifying TouchGFX project for a STM32H735G-Disco for a 7" LCD and FT5446 Touch Controller

[Cino]

Hi everybody,

I successfully created a project for the STM32H735G-Disco. It's rather simple, just two screen with a button in each one. You press the button and you move to the other screen. Nothing more simple than that.

I migrate the project to a custom board which is almost identical to the Disco one with these exceptions :

• ext Flash on OSP1 has a different chip (16Meg vs the original 64Meg)
• 7" LCD
• the Capacitive Touch Controller (integrated in the LCD) is the FT5446 not the FT5336 like in the Disco one.

External Ram chip is the same as in the Disco Board.

After modifying the .ioc file I managed correctly the 7" by adjusting the LTCD parameters according to the LCD datasheet. I also increased the clock of the LTDC peripheral up to 32MHz according to the LCD datasheet. The 7" display works properly.

Then I modified the touch controller driver.

The clue was to compare the content of the FT5336_CHIP_ID_REG with a different value - the FT5446 stores in such a reg a different value respect to the original FT5336 -

I also remove gesture and multitouch features from the driver which was unuseful for my applications (a lot of lines of code)

Of Course I modified the linker file .ld by removing the ext flash section since I still have no external loader for such a flash chip for the STlink.

As far as the external flash is concerned, I also modified the .ioc file by disabling OSP1 and the relative regions in the CORTEX M7 menu in Cube MX.

With these main modifications I was able to have the original project running on the custom board. Well but... here the issues I was unable to fix after several days of attempts:

1. I have tearing effects with screen transitions. From screen1 to screen2 I selected "slide transition" and I actually have the tearing effect. In the opposite transition, from screen2 to screen1 I selected "transition none" and it works fine with very few (maybe absent) tearing effect. I tested all the possible configurations regarding the caching of ram and/or MPU configuration. I also moved from RGB888 to RGB565 for reducing the size of the frame buffer but the tearing effect is still present. Using a double frame buffer doesn't fix the issue.
2. For having the touch controller working properly I was force to put a delay in the STM32TouchController.cpp file (see below)

void STM32TouchController::init()

{

  TS_Init_t hTS;

  hTS.Orientation = TS_SWAP_XY;

  hTS.Accuracy = 0;

  hTS.Width = touchgfx::HAL::FRAME_BUFFER_WIDTH;

  hTS.Height = touchgfx::HAL::FRAME_BUFFER_HEIGHT;

  HAL_Delay(1000); //without it BSP_TS_Init() fails the return code.

//shorter delay fails too.

            //osDelay() crash the system

  tstatus = BSP_TS_Init(0, &hTS);

}

In the past I did almost the same operation for migrating a project from a STM32F746-Disco to a different custom board with same external flash and ram but with the same 7" display. The 7" display was the same I'm using now with the different Touch controller (Panasys NMLCD-70800480 with on board FT5446 touch controller).

At that time the touch driver worked fine - no need to add a 1000ms delay in the STM32TouchController.cpp file, but I have had the same issue with the tearing effects in screen transistion.

At that time, moving from RGB888 to RGB565 worked fine with the STM32F746 custom board derived from the disco.

Since the issue of the tearing effect seems continuing to "follow me" from project to project, please someone have some idea on how to fix it?

And finally, Why should I stop the system for 1 sec at boot for having the Touch controller working properly ?

Thanks for your precious suggestions

Regards

[MM..1]

If i right rememmber for SLIDE you need 3th buffer animation . Too optimize buffers start address.

-- double buffer
    setFrameBufferStartAddresses((void*)disp_mem, (void*)(disp_mem+0x00200000), (void*)0);
-- change to 3 with animation buffer
    setFrameBufferStartAddresses((void*)disp_mem, (void*)(disp_mem+0x00200000), (void*)(disp_mem+0x00400000);

and for touch i dont help, try debug sw + hw

[Osman SOYKURT]

Hello Cino,

As MM..1 said, I think you'll need an animation buffer.

For that in your TouchGFXHAL.cpp file, you'll need to call setFrameBufferStartAddresses() function in the initialize.

void TouchGFXHAL::initialize()
{
...
...
setFrameBufferStartAddresses((void*)FIRST_BUFFER_START_ADDRESS, (void*)SECOND_BUFFER_START_ADDRESS, (void*)ANIMATION_BUFFER_ADDRESS);
}

For the delay, I'm not sure if that would resolve it but try to enable compiler optimizations maybe. Which compiler are you using ?

/Osman

[Cino]

Thank you Osman and MM.1

You were right! with your method, slide transitions from screen1 to screen2 works smoothly as supposed to be.

My project inherit form TouchGFX designer this setup in the void TouchGFXHAL::initialize()

setFrameBufferStartAddresses((void*)0x70000000, (void*)0x70060000, (void*)0x700C0000);

Let me tell you what I discovered after some tests.

By editing the .ioc file in CubeIDE - in the TouchGFX section you can choose between one or two frame buffer and you are asked to the set the starting address of both.

By manipulating this section nothing change in the TouchGFXHAL::initialize() routine which calls setFrameBufferStartAddresses() as you pointed out.

In other words setFrameBufferStartAddresses() retain the arguments inherited when I created the very first time the project in TouchGFX designer.

I followed your suggestion and modify the above line with these values:

setFrameBufferStartAddresses((void*)0x70000000, (void*)0x700BB800, (void*)0x70177000);

0xBB800 is the quantity of RAM needed for 800x480 pixels with 2bytes for RGB565.

With this setting I have no tearing effects and screen transitions are perfectly smooth.

I was surprised that after re-editing the .ioc file nor after re-opening the project with TouchGFX Designer this leads to the modification of such function arguments consistently with the new display data (e.g. 800x480)

Is this a sort of bug or just my ignorance?

I also browse the TouchGFX documentation but I was unable to find reference to the animation frame buffer - and especially when should be used. I thought that the second frame buffer was enough for preventing any tearing effect.

Just for reference, if I use this set up

setFrameBufferStartAddresses((void*)0x70000000, (void*)0x0, (void*)0x0);

everything works perfectly but no slide transition at all. This looks coherent.

As far as the touch driver is concerned, I test several delay time ad at the end I found a minimum value of 200 milliseconds. Without it, the touch controller fail it's initialization.

I tried to follow the code with the debugger step by step but it's just because I used the debugger that I realized that a delay would be necessary for fixing the issue.

In other words - initially, making a step by step debugging on the touch driver leads to the correct functioning of the touch controller while starting the program without any breakpoint active won't.

I'm using TouchGFX 4.20 and STM32CubeIDE 1.10.1 so my compiler is gcc.

Instead of putting a delay in the STM32TouchController::init() like I previously done, you can obtain the same result by removing such a delay from ::init() and introducing it on the main() in the initialization phase :

void main()

.....

 /* Initialize all configured peripherals */

 MX_GPIO_Init();

 MX_CRC_Init();

 MX_LTDC_Init();

 MX_OCTOSPI2_Init();

 MX_I2C4_Init();

 MX_DMA2D_Init();

 HAL_Delay(200); //this delay  MX_TouchGFX_Init() lead to correct operation of the Touch Controller

 MX_TouchGFX_Init();

.....

Any idea about the strange behavior of the touch controller?

Again, thank very much for your help! Without your suggestion I wouldn't be able to fix the tearing effect.

[Cino]

UPDATE

Until now I tested only RGB565 which finally worked fine thanks to the above suggestions.

Moving to RGB888 and changing accordingly the frame buffers addresses in setFrameBufferStartAddresses(), I obtained very bad tearing effects when changing screens with slide transitions.

I read carefully the touchgfx documentation but I was unable to find a possible answer of such behaviour.

The only thing that seems to me plausible is that something is missed for synchronizing DMA2D and LTDC and such syncronization does not come by default.

Again, moving from one lcd to a bigger one exceeding 1Meg (800x480 in RGB888 requires roughly that size) of framebuffer seems cumbersome...

:(

[MM..1]

Read chapter 4.5 LCD-TFT display controller (LTDC) on STM32 MCUs - Application note

[Cino]

Hi,

Thanks for your feedback.

As far as adding dummy bytes, with LTDC the pixel line has to be a multiple of 64 bytes (not pixels). With 800pixel x 3 bytes (color format RGB888),  pad bytes are needed.

I have to find a LTDC line length in bytes (let's say X)  that's a multiple of 64 and a multiple of 3.

X/3 is the line length in pixel, while X/64 are the # of blocks transfered by DMA2D.

I was unable to find a number of pixel accommodating this relation.

I tested also 1024x3 bytes = 3072 bytes.

this means

line length = 3072 / 3 = 1024 pixels

# of block transfers = 3072/64 = 48.

I think is too big. It doesn't work... or something is missed...

As far as the "windowing" method.. i tested it following the application note but I failed...

image is distorted even in static condition... that's a sign that I made a mistake I can't find out after the entire day of testing both solution.

In both cases.. I corrupted the static image of the screen... I mean the screen is fixed but completely distorted.

[nwm_35]

I'm trying to do essentially the same thing as you - use ft5336 code on a ft5436. What is the correct ID number and where did you change it?