How to flash STM32 MCU using USB

[FrankNatoli]

Using IAR to develop software for and burn flash via USB on STM32 7B3I and Discovery eval boards.

Need to develop my own Windows software to burn flash via USB on our own product.

Am familiar with AN2606 [bootloader] and AN3156 [DFU] but neither appear to document how to use host USB to burn client flash.

Can anyone point to a relevant document?

[Tesla DeLorean]

>>That requires programming USB_DM pin and USB_DP pin.

No, that requires a normal USB connectivity between Host and Device using the normal USB protocol.

>>Do you know if Windows applications can use serial port model control signals to toggle USB_DM and/or USB_DP?

Again No, you connect to some class driver/filter driver in the USB driver stack, and use IOCTL to send URB's via that point of attachment. Or you use DLLs that facilitate that type of communications. In DFU mode the packets and descriptor are generally managed in a defined way. Perhaps look at the DFU Device side implementation of the protocols.

AN2606 should tell you which USB is supported in ROM, your own can implement it on either. ROM supports DFU (USB device FS)

..\Repository\STM32Cube_FW_H7_V1.7.0\Projects\STM32H7B3I-EVAL\Applications\USB_Device\DFU_Standalone

https://www.st.com/en/evaluation-tools/stm32h7b3i-eval.html

There's an STM32F723 chip providing ST-LINK connectivity. CN21 into U21, with a SWD/JTAG connection into the H7B3 (U5)

[FrankNatoli]

Perhaps I should have known this, but I've just learned that USB_DM and USB_DP are serial data pins not control signals, akin to DTR or RTS.

I have also learned that, although STM32H7B3I supports two USB ports, HS and FS, apparently only FS can be used for DFU to download firmware, is that correct?

Our target device has two STM32H7B3I systems, both of which over time will of course need to have its firmware updated.

We had planned to connect them to each other via USB-FS, but that would imply no ability to update firmware via DFU with a third device, e.g., a PC, unless the PC updated one of the targets using a port other than USB, e.g., UART or I2C or SPI, which are relatively slow.

In any case, would be grateful for your confirmation that DFU only works with USB-FS.

Thanks.

[Tesla DeLorean]

Wow this is an uphill slog

I've told you

a) The ROM supports USB-FS, per AN2606

b) Your own implementation, running in FLASH, can support both/either, make your software do what you want it too.

c) Pointed at code in the CubeH7 showing Device side code example

If you've got multiple USB devices, connected externally, perhaps use a HUB chip

If the only connectivity you want is the update of a pair of secondary devices, not visible externally, why even use USB for that mode of firmware update. Either use the UART method, or implement a better high-speed UART or SPI protocol to push updates further inward.

[FrankNatoli]

Apologies for "uphill slog".

Was originally working with an STM Discovery board [which only supports USB OTG HS], as an I2C master system, and an STM Eval board [which supports both USB OTG HS and FS], as an I2C slave system.

Because DFU is apparently only supported for USB OTG FS, have substituted a second STM Eval board for the Discovery board.

Our intention is that the I2C master system have its firmware updated via USB OTG FS DFU, and that the I2C slave system have its firmware updated through the I2C master system.

With Eval board SW1=0, on power up Eval board shows two USB ports, STM with PID=374E and OTG FS with PID=5740 [virtual COM port].

With Eval board SW1=1, which documentation says is BOOT mode, on power up Eval board shows only one USB port, STM with PID=374E but no OTG FS with PID=DF11 [DFU Mode]. Also, memory at 0x1FFFA000 still shows all zeroes despite SW1=1 at power up, so there's no DFU code to jump to.

Why is the USB DFU post not enumerating at power up when SW1=1?

Why is BOOT loader not visible at 0x1FFFA000 when SW1=1?

Thanks for your time.

Edit: Windows Device Manager did show a DFU device but no driver.

Found "Zadig" which after download and run made things much better, DFU device OK.

Will now try running dfu-util-master to burn flash.

[MM..1 · Accepted solution]

Ahhh stop your waste time with this USB idea. DFU Driver is part of instalation STM_Programmer from my first post.

When you plan use discovery boards skip trying DFU and use STLINK to every board.

[Pavel A.]

>  DFU Driver is part of instalation STM_Programmer

Sometimes people want to use their own DFU updater app without installing the CubeProgrammer.

I'll try to give a brief explanation how this works on Windows 8.1-10 (and hopefully 11).

Windows does not have a special class driver for DFU devices. Instead, DFU devices are handled by the common winusb driver (or libusb library on top of winusb, or old libusb driver without winusb).

Microsoft does not allow anyone to install a USB *protocol* driver to match any DFU device by protocol. So the winusb driver must be installed only to match the vendor/device ID - which requires a custom driver package, INF file, the signing nuisance ...

There are two ways to avoid a custom driver - if for some reason you don't want the official, signed ST driver (which is winusb under the cover).

One is the "Microsoft WinUSB descriptor" on the device (possible only with user bootloader, not with the STM32 built-in one).

Two: the "Zadig" discovered by the OP. A very cool trick by very clever guy. AFAIK it still works in Win11. So cool that Microsoft doesn't dare to patch it yet.

Or... just use Linux.

-- pa

[FrankNatoli]

Everything finally made sense, was able to burn flash with STM32_Programmer_CLI.exe in DFU mode, many thanks.

I was under the mistaken idea that the management did not want to have customers using STM32 applications or see STM vendor IDs.

In fact, they're OK with STM specifics for flash burn.

They just want the USB OTG FS port under normal operation to have our company vendor ID not STM.

Many thanks again.