Hi. Following this document:
https://touchgfx.zendesk.com/hc/en-us/articles/360020208091-Configuring-STM32F769I-DISCO
and believe all the required changes have been made including applying comments to exclude the STM32 fonts as per this article. However, IAR compiler is raising font related errors.
Any suggestions for a fix? Will review this procedure again to hopefully locate my fault but welcome all feedback. Thanks.
Thanks @Martin KJELDSEN.
Can you post a known good and working project with IAR compiler that targets the STM32F769I-DISCOVERY kit (and uses TouchGFX + CubeMX)? This will help us a great deal.
(venting...)
After 16+ of hours of studying the article here:
https://touchgfx.zendesk.com/hc/en-us/articles/360020208091-Configuring-STM32F769I-DISCO
we do not believe the documentation is complete or we are repeatedly making the same mistakes. About to give up on this and just wait for a proper fix from ST as we have to focus on our projects that will pay the bills.
Our repeated attempts are just yielding a blank display.
More errors that have been caught:
In the project add a sub-group under Drivers called BSP and add the three files stm32f769i_discovery.c, stm32f769i_discovery_qspi.c and stm32f769i_discovery_ts.c which is located in STM32F7Cube installation folder, [STM32F7Cube]Drivers/BSP/STM32769i-Discovery and the file ft5336.c located in [STM32F7Cube]/Drivers/BSP/Components/ft6x06 ???
No such option - should read as "Serial"
Of concern:
1) TouchGFX as a stand alone is using the gcc compiler and perform many hidden tricks. Where can we locate the final compiled binary file that is used to reflash the target memory on the kit? Guess we can study the make file. We wish to confirm that we are truly programming the entire memory ranges of the main memory AND the QSPI flash.
2) What is the role of the QSPI flash? Does the QSPI flash hold the compiled assets? Does IAR upload the final .hex file to both the main flash AND the QSPI flash? Do not think this is working.
3) ST Link utility does not appear to access the QSPI flash. While we can upload the .hex file that is generated by IAR using PROGRAM, the external QSPI flash reports that the file is out of range. Will study the Intel hex file to see if the range of the QSPI is included.
22:17:10 : [STM32F769I_DISCOVERY_021719.hex] opened successfully.
Address Ranges [0x08000000 0x0800CBCD] [0x90000000 0x9008F8B8]
22:17:10 : [STM32F769I_DISCOVERY_021719.hex] checksum : 0x04036EBD
22:17:22 : Memory programmed in 8s and 721ms.Does the above confirm that the QSPI region has been programmed?
We have added the onboard QSPI flash as EXTERNAL LOADER but how do we upload to this memory region using the IAR compiled code?
Receiving the following errors in the log:
(partial log)
What are the details of TouchGFX 4.11? Given that it is CubeMX that is breaking the working TouchGFX toolchain integration, what is the ETA for the next (and working) CubeMX for this kit and STM32F459I-DISCOVERY kit?
4) Also of concern is if the DSI Host is being programmed correctly with the proper clock / timing values after CubeMX breaks the code.
5) CubeMX lists many ports and IP that are exclamation marked which are listed as DISABLED if selected. That is fine yet the tool generates gobs of code that may be the root cause and breaking a working formula. The stand alone TouchGFX does not appear to insert this extra code blocks but what to remove?
In short, gcc is an independent code run that works fine. The CubeMX generator is not working and is like finding a needle in a haystack for the fix. So far, for the past 3 solid days of R&D, just trying to print a simple graphic and button. No touch access yet. All black on the display.
