TouchGFX generated project is not worked on STM32F746G-DISCO(C01)

[Yuki]

The project automatically generated by TouchGFX worked fine in the simulation but not when downloaded to the target.

Also, when I used the STM32CubeIDE to run it from debug mode, it worked fine.

It looks like the boot mode is the cause, but I didn't know the details. The target board (STM32F746G-DISCO) is in the factory state, and most of the project sources are the same as when they were automatically generated.

I couldn't find a solution because the auto-generated project doesn't work.

Do you have a solution or know about this problem?

My environment is as follows:

​TouchGFX 4.19.1

STM32F746G-DISCO (board edition: F746NGH6-C01)

(STM32CubeIDE 1.9.0)

[Osman SOYKURT]

Hello Yuki,

Any news about your issue ?

/Osman

[Yuki]

Hello Osman,

Sorry for the delay in getting back to you.

I have not been able to work on this issue much in the past, but I have had some results, which I will describe here.

1. I unzipped the project you gave me and tried to write the binaries there, but they did not work.

2. I thought the problem was in the development environment, so I reinstalled all the software and rebuilt the development environment. However, this did not solve the problem.

3. Next, thinking that the host PC might be incompatible, I prepared a completely different host PC and built a new environment, but it did not work in this way either.

4. I found a demo binary on the official ST site, wrote it, and everything worked perfectly fine! The possibility of a hardware glitch is now very low. (I should have tried it earlier...)

5. Finally I added a behavior to the source code to turn off the display after 10 seconds, it worked correctly and the display turned off after 10 seconds. Although it did not respond to touch operation, it seemed to continue to work internally.

These results led me to believe that there is something wrong with the touchscreen, but I have yet to solve the problem.

If I find any solutions, I will try to reply here again.

Yuki

[TMack.1]

I have the same problem as Yuki.

​TouchGFX 4.19.1

STM32F746G-DISCO

STM32CubeIDE 1.9.0

A new project generated in TouchGFX Designer using the STM32F746G Disco board setup.

Programmed via cubeIDE (either debug or run (debug or release build)) and it runs. However reset or power cycle the board and the UI displays (complete with animation) but the touch does not work.

Programming via cubeprogrammer (with update to date stlink and external loader) it programs and verifies ok but when it runs the touch does not work. The animation does run and a reset or power cycle does not change things.

The app is 99% TouchGFX generated (just updating a text box on touch events done by me) so I am struggling to see what I could have done wrong. So I am guessing there is something in the i2c or touch setup that is not being done properly?

Unfortunately this was supposed to be a quick trial of TouchGFX to see if it is suitable for a couple of new products and I don't really have time for in depth debugging of code I did not write, especially as when using the debugger the issue does not occur :downcast_face_with_sweat:

I cannot link my project file (forum gives a new members cannot do that warning) but if you want to find it then reconstruct the following.....

h t t p s : / /

www dot dropbox dot com

/s/yd532a1qy1mj66p/MyApplication_1-snap2.zip?dl=0

Toby

[TMack.1]

I have done a bit of debugging (toggling an IO pin at various points) and it does look like the i2c system is not initialised properly.

I have traced it down from STM32TouchController::sampleTouch() and it works down as far as HAL_I2C_Mem_Read().

When working normally (ie after programming via CubeIDE) it takes 400us to run HAL_I2C_Mem_Read() (not touching the display). After a reset it takes 200 to 350ns.

Digging further, when failed, in HAL_I2C_Mem_Read() it never gets past the initial

"if (hi2c->State == HAL_I2C_STATE_READY)" condition.

In fact, adding a check for hi2c->State shows that it is HAL_I2C_STATE_RESET.

I have not working out if this is because it was never initialised or was initialised but something reset it but that is all I have time for at the moment.

Toby

[TMack.1]

I have now really run out of time to spend on this but I have now traced this to the fact the I2C is initialised and I2C writes and reads work as expected but only when programmed via GDB (ie from CubeIDE).

On a reset the initialisation still occurs but the first I2C access (a write from ft5336_TS_DisableIT()) fails so I2C is disabled.

ft5336_TS_DisableIT() is called as a result of MX_TouchGFX_Init() being called in main().

So, as an experiment, I put a delay before the call to MX_I2C3_Init() in main().

eg.

 HAL_Delay(1000); // tjm debug

 MX_I2C3_Init();

It now works after a reset or power cycle!

I am not proposing this as a solution but it gives a pretty strong indication of a bug in the I2C initialisation.

I am unlikely to look at this further but hopefully it will help others who might have this issue.

Toby

[ABerg.8]

Hello Oskt, I have the same problem, my applications do not run on other boards with the number F746C01, the touch panel works after building. if the reset button is pressed, or the power supply is interrupted and reconnected, the touch panel no longer reacts. However, data that I send via USB or CAN are displayed. So something is different with the touch panel. The display also has a slightly different look, and the color of the LEDs inside is more yellowish, apparently the manufacturer has installed a different display and touch panel.

[ABerg.8]

Hello Oskt, I have the same problem, my applications run on older boards. Not on the one bought 2 weeks ago with number F746C01. The touch panel works after building. if the reset button is pressed, or the power supply is interrupted and reconnected, the touch panel no longer reacts. However, data that I send via USB or CAN are displayed. So something is different with the touch panel. The display also has a slightly different look, and the color of the LEDs inside is more yellowish, apparently the manufacturer has installed a different display and touch panel.

[ABerg.8]

Hello TMark1, your solution worked for me too , HAL_Delay(100); was enough. Thank you

[Paphael]

Hi,

I have the same problem.

Only the "touch screen" doesn't work.

My board doesn't work with hardware reset, but it works with STM32CubeProgrammer.

What is the reason for this?

[Osman SOYKURT]

Hello Paphael,

A solution is shared in this thread.

/Osman