Skip to main content
andywild2
andywild2
Associate III
November 26, 2020
Question

TouchGFX Examples for STM32F769I-EVAL produce memoryfault

  • November 26, 2020
  • 3 replies
  • 1056 views

Hello,

I am evaluating TouchGFX 4.15 with STM32F769I-EVAL and MDK-ARM.

I can successfully compile the code of the Animated Image Example and download it using MDK-Arm and ST-Link. However the CPU hangs in MemoryFault when it first enters TouchGFXHAL::taskEntry() and proceeds to function backPorchExited();

In backPorchExited(); the swapping of the framebuffers obviously cause the MemoyFault.

I didn´t change anything in the configuration auf CubeMX, I just wanted to test this simple example.

Any help is very welcome

Andy

Attached the CoubeMX

This topic has been closed for replies.

3 replies

andywild2
andywild2Author
Associate III
November 26, 2020

Hello,

I did some more debugging:

It has nothing to with RAM and framebuffers. The program runs until BSP_TS_GetState(TS_StateTypeDef* TS_State).

In here there is this statement:

TS_State->touchDetected = ts_driver->DetectTouch(I2C_Address);

However ts_driver = 0 (NULL). So the function DetectTouch is never called, the system crashes here.

Why is ts_driver not initialized??

Please help

Andi

andywild2
andywild2Author
Associate III
November 26, 2020

Again more Debugging:

In BSP_TS_Init(uint16_t ts_SizeX, uint16_t ts_SizeY) the fetching of the ID Value

 if (ft6x06_ts_drv.ReadID(TS_I2C_ADDRESS) == FT6206_ID_VALUE)

fails with I2C Errorcode HAL_I2C_ERROR_AF = 0x04

That´s why ts_driver is not initialized!

But with other KEIL-Examples the touch is working! So it is not a hardware fault!

I have no glue why this doesn´t work.

I think a beginner in TouchGFX is NOT supposed to dig so deep into the code, just to get the first TouchGFX example ever to function...

Hoping on a simple solution

Andy

andywild2
andywild2Author
Associate III
November 27, 2020

Found the fault finally.

The function BSP_TS_Init(uint16_t ts_SizeX, uint16_t ts_SizeY) is normally provided by the Board Support Package of ST which is currently Ver 2.13.0.

In here this function is located in the file stm32f769i_eval_ts.c. This function in BSP 2.13.0 TAKES CARE of 2 versions of STM32F769I-EVAL: Version A and Version B.

Version A TouchController I2C adress = 0x54, Version B TouchController I2C adress = 0x70.

So the function is kept up to date bei ST Microelectronics, which is good.

BUT: The TouchGFX Generator creates HIS OWN BSP_TS_Init(uint16_t ts_SizeX, uint16_t ts_SizeY) which is located in STM32TouchController.cpp.

And this function DOES NOT TAKE care of the two versions of the board!! It assumes the I2C adress = 0x54.

The point is: If TouchGFX Generator does its work in such a strange behaviour (that is not using the newest libraries of ST), how can I rely on this product in the future when things become really tricky and not just a wrong I2C adress?

I have chosen TouchGFX instead of STemwin or Embedded Wizard because of nice demos and good documentation, say good marketing...

But if I have to cope with such issues from the very beginning, how can I justify my decision to my clients?

Looking forward for a good answer of the developers of TouchGFX.

Have a nice weekend

Andy

Terms & ConditionsAccessibility statement