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.

[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

[Mon2]

@Martin KJELDSEN​ , you must have nightmares about this forum :)

Adding to your pile, here is what we see when attempting to upload the .hex file with ST Link utility:

Will dig around to see if we can find a manual to better understand how the external flash should be programmed. We have manually erased the sectors of the external flash but apparently unable to program it?

In using Target -> Program - believe this is only programming the main flash inside the CPU and not the external QSPI flash.

[Mon2]

@Martin KJELDSEN​  - fairly confident we just got this working!!! At last. Repeated the results now 3 times.

IAR is complaining about something but it appears to upload the graphic that was generated by TouchGFX. Have not yet applied the touch screen support which will follow (if the new 2.0.0 template does not do this already).

Also, performed a full chip erase with ST Link and then reflashed using only the custom generated .hex file and all is looking good.

Will verify the steps and document asap before we forget.

Many thanks again for your continued support.

[Martin KJELDSEN]

@Mon2​,

I love your dedication! =)

You're using the right ST-Link external flash loader. MX25L512G_STM32F769I-DISCO.stldr.

There's no external flashloader configured in (almost) any of our EWARM or MDKARM projects. That's most likely the "error" you're getting with IAR; It's just saying that it doesn't have any means of programming 0x90000000->. Programming should be done through ST-Link or STCubeProgrammer. That's also a bit difficult to communicate.

v2.0.0 of the Application template is fully functional, with touch support.

You're so very welcome. I appreciate your spirit and you seem to never give up. Maybe we should try to summarize what you've "been through" here, if you want.

Best regards,

Martin

[Mon2]

Dedication? More like an obsession =) It is our day off locally and nothing better to do, that is my excuse and sticking with it =) Keeps the mind going.

Agree on the very nice 2.0.0 template. Well done!! The results are much much better. Will document this for the future readers but finding that:

a) best if the gcc compiler compiles the code and generates the respective output files for the flash

b) ST Link is good to reflash the board. So far, appears that the external flash is not being used. Performed an erase of 4 sectors @ 0x9000... and no impact on the generated graphics

c) to be honest, IAR is now just a fancy project editor and guess a debugger AFTER ST Link flashes the board?

Regardless, IT WORKS!!

Need to get this off the table so can concentrate on our company widgets. Tentatively planning to meet up with some LCD display mfrs in Asia in April to discuss valid alternatives to the OTM LCD controller. That is something of interest to us since OTM is EOL.

Thanks again.

[Martin KJELDSEN]

Haha, sounds like a nice day to have!

a) If you use the Makefile instead of the designer, you can type "make intflash". It will program the intflash.hex file to 0x08... only, leaving out the assets.

b) I don't quite understand that. Does your application have images or text at all? It should definitely, by default, use the QSPI of the board. Maybe you succesfully programmed the QSPI once, and just the internal flash subsequently and now you think it's not needed? From your ST-Link output it looks like the .hex file contains a range into the 0x9000...s

Maybe you could share your findings after you meet up with these manufacturers? That'd be interesting!

Best regards,

Martin