2020-11-26 09:35 AM
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
2020-11-26 10:06 AM
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
2020-11-26 10:40 AM
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
2020-11-27 05:07 AM
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