Compiling for STM32F769I Discovery

[Mon2]

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.

[Martin KJELDSEN]

Hi @Mon2​,

I will double check the article. From your compiler errors it looks like either an include is missing or some code is there that shouldn't be (We do not use or need the standard drawing methods provided by _lcd.c)

You could try to simply remove that code for now that the compiler is complaining about. If it's related to lcd drawing methods (sFont, drawRect, etc) you can just ommit it since it is not used by TouchGFX.

Sorry for the trouble!

Best regards,

Martin

[Mon2]

Thanks @Martin KJELDSEN​. Removed a file that we may have added in error and somehow hacked our way into an error free compilation but generating a black screen on the display. If we launch the TouchGFX tool as a stand alone, the gcc generated code works fine (although the touch response with a decay timer to fade the posted graphic appears to be quite slow with 3000ms steps). Regardless, the display works and the 2 graphics with touch access are operating correctly.

Will review the same document again but noting at least one typo in the article:

under Add code, step 2 should read:

//
// typo on Draupner website - the 'f' is missing in the filename
//
#include <stm32f769i_discovery_ts.h>

 Sorry - also wish to ask, are the LCD parameters correct for this kit as show in this article vs. the STMCubeMX tool?

Is the display onboard the kit not 800x480? Respectively, the article is listing different values.

For example, in the GUI screen for STMCubeMX, the Active Width = 400 but should this be 800?

Same concern for the Layer Setting table of values - is that valid for the 800x480 display?

Thanks!

[Martin KJELDSEN]

Hi @Mon2​,

Thanks for the heads up on the typo.

Regarding the active width: Yes the display is 800x480. The CubeMX setup can seem a bit confusing. It is to generate a configuration that transfers parts of the display (depending on 16bpp or 24bpp) rather than the whole thing in one go, to avoid tearing. So the Active Width would be either 400 (Two chunks) or 200 (4 chunks). It's difficult to communicate that through CubeMX and i can understand your confusion.

Best regards,

Martin

[Mon2]

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.

[Martin KJELDSEN]

Hi @Mon2​,

Let me just answer quickly on just one of your questions which seems the most pressing.

If you create a new application using v2.0.0 of the STM32F769-DISCO Application Template we've already done the work to make gcc/IAR work (No Keil support); Essentially what the article is supposed to document.

The article probably isn't perfect, as you've pointed out. I'll add it to the list of things to rectify =) I'll get back to you on your remaining questions.

Thanks!

[Mon2]

@Martin KJELDSEN​, from where can we download this v2.0 STM32F769I-DISCOVERY Application Template? Pretty sure we are on v1.1.0 if my memory serves me correctly but been at this far too long.

Thanks!

[Mon2]

Never mind - found it. Sorry but that was NOT easy to find. Will review. Bye for now.

[Martin KJELDSEN]

I know :) Glad you found it!

[Martin KJELDSEN]

@Mon2​,

1) "Where can we locate the final compiled binary?"

Yes, this is confusing. I've flagged this already but i'm not sure it'll make it for next release. It's inside (For v2.0.0 of the application template) TouchGFX/Build/bin/. There you can find both elf and hex files for internal flash (code only) and external flash (assets) and the full binary for both internal and external flash. For v1.0.0 it will just be build/bin.

2) "What is the role of the QSPI flash?

The QSPI holds images and texts (By default - You can change the linker script to place things differently). The converter tools append a pragma and additional attributes to the converted data so that the linker will place it correctly). e.g. LOCATION_EXTFLASH_PRAGMA and LOCATION_EXTFLASH_ATTRIBUTE. A config file in touchgfx will define these differently depending on the compiler.

e.g. for the IAR linker script - The TouchGFX config file for EWARM tags images and texts with ExtFlashSection:

define QSPI_region .... //0x90000000 to 0x93000000
place in QSPI_region { section ExtFlashSection };

3) (Minus the log part)

"ST Link utility does not appear to access the QSPI flash. "

You must add the external flashloader for your board manually. I think you said you did this? Then it will recognize that it can program 0x90000000->. Are you sure you've added the right flashloader?

Best regards,

Martin

[Mon2]

@Martin KJELDSEN​ , "getting closer" - have a scrambled graphic of my GUI page and/or a view of someone who has had too much to drink :)

Does IAR require special config for the external flash device? We did add the external loader QSPI flash with the ST Link utility but have not been able to upload to it using the .hex file.

Also, our kit was on an older ST firmware - just reflashed to version 33

IAR is raising errors:

[Mon2]

Sorry - ignore for now - just noted that we are uploading code from YESTERDAY but testing a new code run....

:( St Link still complains with the new fresh .hex file that is posted below. Welcome feedback.

Hi @Martin KJELDSEN​ , here is what we see with the ST Link utility which we believe is properly defined for the external QSPI flash. Is the DISCO board the same as the Discovery Board? It is the same looking board as shown in your TouchGFX start menu.

So we know that IAR does not like the external flash region and now the ST Link does not appear to be programming the mapped external flash as well? However, the .hex file appears to be complete for our compiled code.

Posting it here:

https://we.tl/t-PSsOJUj20J