Is OpenBootloader a good starting point for DFU on STM32H750 with RS485 and QSPI NOR?

[MScor.1]

We need a DFU-capable bootloader for a custom board based on the STM32H750.

We can't use the ROM bootloader due to 2 requirements:

1. upload of the DFU image needs to happen over RS-485, with support for DE to an external transceiver
2. we need to flash the DFU image to a QSPI NOR Flash (MT25QL512)

It looks like the OpenBootloader that is available for STM32G0 and STM32G4 would be a good starting point, but it would require porting to the STM32H750.

Is there a better option? Are we going to waste time trying to go in that direction?

[KDJEM.1]

Hello @MScor.1​ and welcome to the STCommunity :) ,

To develop a Bootloader, you can use the OpenBootloader package called (OpenBL), that behaves exactly like the system bootloader.

For the moment, OpenBL supports only STM32G0 and STM32G4 series:

• \STM32Cube_FW_G4_V1.x.x\Middlewares\ST\OpenBootloader
• \STM32Cube_FW_G4_V1.x.x\Projects\NUCLEO-G491RE\Applications\OpenBootloader

So, you can customize it for other products series like STM32H7 according to your needs.

More information on USB DFU protocol used in the STM32 bootloader is available AN3156.

I recommend also that you refer to the FAQ STM32 boot process and application note AN2606 "STM32 microcontroller system memory boot mode", and you find related information to STM32H7xx bootloader.

 Hope my answer helped you!

Kaouthar

[Tesla DeLorean]

>>Are we going to waste time trying to go in that direction?

Hard to say, do things in an incremental and reusable way.

If you get a good working BSP to handle writing to QSPI, you open the window to supporting a DFU or MSC Device, or X/Y-Modem serial methods, or write a FAT file system to the QSPI memory to stage updates, patches, or content.

Generally I think time spent coming up with flexible and robust update methods almost always pays significant benefits when it comes to technical support costs, phone time and user/staff frustration.

I'm comfortable with writing loaders, etc. so less likely to pull in external tools, but if this is a new area for you reviewing Open Boot Loader, in a code-review / functionality sense might at the very least give you ideas of how/what you ultimately want to build. Listen to your support team.

[MScor.1]

Oh, I am sure that spending time to get a DFU properly in place is not a waste of time, sorry for not being clear.

What I meant to ask was whether porting OpenBootloader from the G0/G4 to the H7 was a waste of time.

In any case, we have started the process, building from a clean CubeMX project for our board and bringing in OpenBooloader related files. We have SDRAM and QSPI support working at the fundamental level and we can already jump into the application from OpenBL, so now it's mostly a matter of bringing the DFU together:

• registering the QSPI NOR with the OPENBL_MEM module
• registering the 485 interface as a OPENBL_USART
• test, test, test =)