DFU files and setting option bytes using CubeProgrammer_API

[unicyclebloke]

My project is using an STM32U575.

I have been studying the DfuSe file format and wondered if this can be used to change the values of option bytes. I can see that CubeProgrammer_API used strings such as "-ob nSWBOOT0=1" with sendOptionByteCmd(). If I were to include a target in a DfuSe file whose address is one of the option byte registers, would this successfully change the option bytes? That is to say, is the bootloader smart enough to handle writes to option bytes (presumably by spotting the target address)? In firmware, this is more complicated than writing to regular flash.

For context: 

We are performing firmware update over USB using the built-in ST bootloader. The update is initiated in the firmware by changing the nSWBOOT0 option bit and resetting, which runs the bootloader. So far, we have then used STM32CubeProgrammer to connect to the device and send the latest BIN image. After that, we use STM32CubeProgrammer to change the option bit again, and then reset to run the new firmware. This works well enough, but the client wants a custom tool integrated with a PC application (which we have also written).

I've looked at CubeProgrammer_API USB_Example.cpp and could certainly make that work. Unfortunately, the API comes as a DLL (no source code that I could find) with quite a lot of dependencies such as Qt6. This made me wonder about implementing a DFU update directly on top of WinUSB. This amounts to transferring a file which the bootloader on the STM32 decodes. 

[Aziz BRIGUI · Accepted solution]

Hello @unicyclebloke,

STM32CubeProgrammer does not support the .dfu extension.

Aziz 

[unicyclebloke]

That's a little surprising given that ST went to the trouble of creating the DfuSe format. It turns out that writing the option bytes as a separate image within the file works well. The bootloader changes the option bytes and immediately resets the device. I was able to update the device by sending a DFU file with dfu-util (which understands the DfuSe extensions). It's curious that ST don't support their own file format. 

I have since written my own C++ library (dfu-util is not a good fit) to communicate with the ST DFU bootloader, which deals specifically with DfuSe files and takes care of erasing the necessary pages and whatnot. I suppose in this case I could just use a custom file format, but there seems no reason not to use DfuSe. I may extend it to allow individual option bits to be managed with a read/modify/write operation...