Identifying stm32F407 vs stm32F411

[noisymime]

Is there any way at all in PC software (Either the ST libraries or things like libUSB) to identify whether a device in DFU/Bootloader mode is an F407 or F411? Everything I can find in the USB properties is identical between the two (Same VID/PID, same bcd identifiers, same device and control descriptors etc). I need a way to determine which firmware version to load on based on the device itself, but there doesn't seem to be any identifying properties for them.

Anyone know if there is something that can be used to figure out which device is plugged in?

[BarryWhit]

I have not tested this, but I think it should work. The STM32 bootloader provides a command interface which includes a "READ MEMORY" command. This is true also when you talk to the loader over USB in DFU mode. You could try and see if you can read the DBGMCU_IDCODE register or some other register that can distinguish one device type from another.

See AN3156: USB DFU Protocol Used In The STM32 Bootloader  and the reference manual for you chip.

(This useful Post links all the bootloader appnotes in one place)

It may be quickest to first test this idea out using the UART bootloader interface instead, If you don't already have a custom DFU application on the host side.

Please report your results back here, I'd be interested to know if it works.

Depending on your context, you might also be able to get away with relying on some pattern in the serial numbers (which is part pf the USB descriptor), if for example you had a bunch of boards assembled from a single reel of components. But I wouldn't recommend it.

[noisymime]

Thanks for that, I think that's probably the best option. I'd hoped to avoid having to go into DFU land and use just what the board identifies as to the OS, but looking like that isn't possible.

Depending on your context, you might also be able to get away with relying on some pattern in the serial numbers (which is part pf the USB descriptor), if for example you had a bunch of boards assembled from a single reel of components. But I wouldn't recommend it.

---

I did look at this as well as serial number was basically the only field that appeared different between the 2 in the USB descriptor (Other than physical port numbers etc). I couldn't find any details or patterns around serial numbers vs model though and I didn't dig much further into it. Feels like it would be a fragile solution anyway as serial numbers could easily change format batch to batch I imagine.

Again, thanks for the reply. I'll dig into the DFU side of things and see what I can find.

[BarryWhit]

I'm not familiar with the F4 family, but Assuming they are similar enough, it may also be possible to design a "universal" firmware with feature flags based on chip type, or at least a universal program that would report the chip type to the PC, which would then reprogram them with dedicated firmware. But I think the DFU route is a the best solution. There's also open-source code out there, so most of the work has already been done for you.

Good luck, and please post an update when you have one. This information would be useful to others.

[BarryWhit]

I was curious about this and so I did some test on my STM32G431 board. I found out some things.

0. According to AN2606rev63 table 196 (Bootloader device-dependent parameters), STM32F407 should have a PID of 0x413, and STM32F411 has a similar but different PID of 0x431. Are you absolutely sure the two chips give you the same PID?

1. STM32CubeProgrammer can connect to your chip using ST-LINK, but also using the USB-DFU mode (in the GUI it's just called "USB") and also USART.  There's no need to hack code to test things out.

2. STM32CubeProgrammer has a handy register browser but only in st-link mode. It also has a memory browser, which I tried (with verbosity=3). I can scucesfully read the expected value over ST-LINK. Unfortunately, as far as I can tell, the DBGMCU registers reside in a memory range which is not accessible via USB-DFU. So that's a dead-end.

3. However, when connecting, STM32CubeProgrammer is somehow able to read the "DEVICE ID". The value  appears in a little status box at the lower-right of the GUI under "device information". This is exactly what you're looking for.

4. The bootloader application notes seems to suggest (perhaps misleadingly) that different interfaces support different command subsets.  For example, "AN3155 - USART protocol used in the STM32 bootloader" says that the bootloader supports a "GetID" command. But "AN3156 - USB DFU protocol used in the STM32 bootloader" doesn't list that as a supported command (although there is a GET command which returns a list of supported commands. I can't access that command with STM32CubeProgrammer).

My best guess is that USB-DFU supports the GetID command as well, but that this is undocumented. If it doesn't, there is still definitely a way to read the Device ID over USB-DFU, since the STM32CubeProgrammer does it.  In the worst case, you could find out how it does this fairly easily with a USB analyzer (even with wireshark).

But first, let's try the "Bat Signal"...

[BarryWhit]

Dear @Imen.D,

- Can you confirm that the USB-DFU bootloader supports the "Get Device ID" command? (according to AN3155, the bootloader does support this command over USART)

- If "Get Device ID" *is* supported over USB-DFU, why is this not documented in "AN3156 - USB DFU protocol used in the STM32 bootloader"?

- If "Get Device ID" is *not* supported over USB-DFU, how does STM32CubeProgrammer get the Device Id reported in the GUI after establishing a connection of type "USB"? does it just blindly copy the PID of the device?