Stm32f469-disco support

[physwm2501]

Is it difficult to implement the boot loader to work on this board? I’ve been working on a uart update tool that triggers from the application as I don’t have access to the buttons on this board. I can update the basic application without issue but have been working on being able to bring over the touchgfx assets as well.

[firmwareguru]

It shouldn't be a problem to support the 32F469IDISCOVERY board. I have already got the F769I discovery board supported. I don't have a 32F469IDISCOVERY board on hand, however, but can pick one up. It would take a bit of time to get all the BSP stuff glued in and working.

Can you elaborate on what your UART update tool is doing?

[physwm2501]

My current setup is fairly straight forward.

1. I have a gui update button in my touchgfx program that points to my custom bootloader. I have verified this is initializing correctly by going to both my bootloader and pointing to the st bootloader.
2. Using YMODEM over uart I send the .hex file over.
3. This correctly updates my code in the 0x08004000 location but not any assets in QSPI located in 0x90000000.

[firmwareguru]

Not sure from your description if it is your bootloader or ST's built-in bootloader that is parsing the .hex file. If it is your bootloader that is doing the parsing/updating, then it should be straight forward to pass off the data from hex record addresses destined to the external flash region to the BSP QSPI flash driver write API BSP_QSPI_Write(). You need to pull the BSP QSPI stuff into your bootloader from, for example, here: https://github.com/STMicroelectronics/32f469idiscovery-bsp. This should be enough to get you going for this basic level of functionality.

The stm32-secure-patching-bootloader effectively does all that, but also adds ability to distribute a combined .bin file instead of a .hex (.bin is much smaller). The combined .bin update file is wrapped up with encryption and a digital signature and becomes an .sfb file. Patch files (differences from existing load to a new one) can also be generated on these combined .bin files (these become .sfbp files). There is also in-application update capability (you could download an update over cellular, ethernet, bluetooth, whatever). And I also have a USB flash update method (FatFS stack and USB MSC) integrated in the bootloader if a board supports it.

I'm working on getting a v1.3.0 release out, and after that I can look at DISCO-F469I support.

[physwm2501]

Current update is with my own bootloader. I can load into the ST built-in bootloader without issue and update over both st-link and dfu with no issues. Since I don't have access to either of those when everything is enclosed I need to get things running over the usuart6 port. I'll look more into the QSPI write, on the bootloader front it would be ideal to have the bootloader take in 1 hex file and manage the update from there. Since I'm on AC power I don't have restrictions on being too efficient.

There isn't much need for security in my application but the patch files would greatly speed up the update process, especially since it's rare touchgfx assets are being updated. Been looking more into the secure patch tool to see if that would get a cleaner solution in the end..

I'll keep my eyes out for v1.3.0 as this seems to do everything I've been trying and more. Thanks for the input so far, I always prefer to understand how my software works.

[firmwareguru]

The DISCO-F469I board support is now available in the v1.4 preview branch.

There is a full TouchGFX integration reference design at https://github.com/firmwaremodules/STM32CubeF4/tree/v1.4-preview/Projects/STM32469I-Discovery/Demonstrations/TouchGFX

[physwm2501]

That works quite seamlessly. Still working on my own implementation as I need functionality over USart6.