Built-in DFU bootloader and bAlternateSetting

[unicyclebloke]

Apologies if this is the wrong group for this query. 

I have implemented a library from scratch which performs the host side of a DFU upgrade (avoids the dependencies in CubeProgrammer_API.dll, for which I could not find source). The code works just fine but I have a question about the expected values of bAlternateSetting across the whole range of STM32 devices.

For the STM32U575, there are three DFU Interface Descriptors with bAlternateSetting values of 0, 1 and 2. These correspond to 0=Internal Flash, 1=Option Bytes, 2=OTP Memory. [This is very clear from the memory descriptor string corresponding to the iInterface value of each interface.]

My question is: are these values consistent across the range of STM32s, or might some devices have (say) 1=Internal Flash or whatever?

Is there any available documentation for this? I've spent quite a bit of time trawling various UMxxxx and ANxxxx as part of creating this library, but have not found much about bAlternateSetting.

The behaviour of DFU_DNLOAD is a little different between Internal Flash and Option Bytes, so I wondered if I could switch on the value of bAlternateSetting to tailor what my code does. For example, the device immediately resets after writing the Option Bytes. 

Thanks. 

[STOne-32 · Accepted solution]

Dear @unicyclebloke ,

That is a nice question and as far as I Know the first time a customer asked for it since the first time we introduced DFU class for ST products even before STM32 , 20 years ago :)

Our Specific DFU implementation is described here : UM0424

https://www.st.com/resource/en/user_manual/um0424-stm32-usbfsdevice-development-kit-stmicroelectronics.pdf
see Table 28 and how to decode / design the string descriptors of the Memory mapping : Size of the pages / sectors , you can read or Erase, Write etc..

in General for the built-in factory bootloader :

0 : is Flash memory , then Options bytes in 1 and after specific MCU HW features such as OTP etc, 

Hope it helps you ,

Ciao

STOne-32

[unicyclebloke]

Thanks for the response. 

I found UM0424 already and read Section 10. Very useful. I can see that the memory mapping strings includes a name such as "Internal flash", but was just to trying to establish whether there is a reliable numerical indication in the bAlternateSetting value. My take away from your comment is "Yes for 0 and 1. Maybe not so much otherwise". That's fine. We can test each type of device as we go along. 

I had great fun implementing this code but found it much more difficult to understand than communicating with the bootloader over the UART interface. The issue was that information was quite sparse and incomplete. I had to spend quite a bit of time trawling through other code bases such as that installed with STSW-STM32080, and even the internals of dfu-util, to glean answer some of my questions. I was initially surprised that I could find only very few implementations of DFU in general and DfuSe in particular, but maybe that was not so surprising after all. :)

I do have a suggestion for ST. Release something like CubeProgrammer_API.dll which depends only on standard Windows system libraries. Or, better, release a static library which could be linked to a custom application which could be released as a standalone executable (which depends only on Windows system libraries).

Context: I only started my implementation because I need to add DFU capability to a PC application which my client's users install to configure the firmware, read logs and so on. The available options all seemed to involve installing a lot of dependencies and/or shelling out to another executable (dfu-util). None of these were desirable. I have seen that others have raised the issue of dependencies in the ST DLL. Apologies if I overlooked something that already exists. I found DfuSe_Demo_V3.0.6_Setup (in STSW-STM32080), but understood the code to be obsolete.  

My own DFU code is in C++, but I will ask about the possibility of making it open-source. There are some hurdles to overcome for that...