Showing results for 
Search instead for 
Did you mean: 

FAQ : STM32MP1 STM32CubeProgrammer USB reconnect error at STM32MP1 boot device flashing

You want to populate the boot device of the STM32MP1 with STM32CubeProgrammer, the bootpins drives correctly the boot ROM to load binaries from the serial USB-OTG port.

You can load the FSBL and U-Boot with STM32cubeprogrammer,

but U-Boot resets the usb and the STM32cubeprogrammer can never reconnect, returns a timeout error as below.


~/STM32MPU_workspace/STM32MP15-Ecosystem-v1.0.0/Starter-Package/stm32mp1-openstlinux-4.19-thud-mp1-19-02-20/images/stm32mp1$ STM32_Programmer_CLI -c port=usb1 -w flashlayout_st-image-weston/FlashLayout_sdcard_stm32mp157c-ev1-trusted.tsv



STM32CubeProgrammer v2.0.0





RUNNING Program ...

PartID: :0x03


reconnecting the device ...


Error: unable to reconnect the target device: time out expired 

Error: Start operation failed at partition 0x03

Error: TSV flashing service failed


<end of the log >


 > and USB identification message is never coming up on ST32CubeProgrammer console


"USB speed   : High Speed (480MBit/s)

Manuf. ID   : STMicroelectronics

Product ID  : USB download gadget@Device ID /0x500, @Revision ID /0x0000

SN          : 003100363338511534383330

FW version  : 0x0110

Device ID   : 0x0500"




When reset is de-asserted , the RomCode initializes the USB-OTG port as USB peripheral to enable DownloadFirmwareUpdate (DFU) in SYSRAM. STM32MP1 is identified by PC host as 'DFU in HS Mode @Device ID /0x500, @Revision ID /0x0000"

The USB-OTG controller HW configuration used during the FSBL and Uboot loading is the configuration initiated by the bootROM (OTG with HS PHY , HUSB_DP2/USB_DM2 pin (OTG_HS_DP/OTG_HS_DM Alt funct.)


Before Uboot DFU flashing service is started by Uboot autoboot (call to stm32prog usb 0), the FSBL STM32MP1 triggers a USB  disconnect to the PC host, then Uboot re-initializes USB-OTG controller and answers to PC enumeration request to register STM32MP1 as " USB download gadget@Device ID /0x500, @Revision ID /0x0000".


The USB PC-STM32MP1 re-connection can fail when Uboot DT configuration that does not match USB OTG_VBUS/OTG_ID pins of the actual PCB or if Power supplies of USB subsystem is disabled.


There are two difference between the ROMcode OTG initialization and the Uboot OTG initialization.

  • The ROM code does not takes into account OTG_VBUS pin , it directly put OTG peripheral powered state
    (OTG_GOTGCTL bits allow to make IP OTG behave as if VBUS is 1. ROMCode sets to 1 the following two bits Bit 7 BVALOVAL Bit 6 BVALOEN).
  • The ROM code configures OTG controller as Peripheral Only and OTG_ID is ignored.


To check


  • If you are using a VM, check the USB 'connection' between Linux and Windows as uBoot reconnect using a different USB identification and might not be 'routed' to the VM.
    In VMWare, you have a menu Player/Removable Devices where you can choose which devices that belong to Virtual Machine or to Windows. In VirtualBox it should have similar setting.


When uBoot start up, check at that time in your VM if you have 'USB download gadget@Device ID /0x500, @Revision ID /0x0000)' as a new removable device to 'connect' to your Virtual Machine.


  • If you are using a native Linux PC check you "see" Uboot configured as a USB peripheral


In Uboot shell run a Dfu command  :

  STM32MP> env set dfu_alt_info "DDR ram 0xC0000000 0x20000000"

  STM32MP> dfu 0 ram 0


This U-Boot command is infinite, USB stack continue until CtrlC….

Now you should see the USB on the Linux PC console the USB Product "USB download gadget" of Uboot configured as an USB peripheral


PC$> dmesg


[17802.822239] usb 5- new high-speed USB device number 10 using xhci_hcd

[17802.922995] usb 5- New USB device found, idVendor=0483, idProduct=df11

[17802.922998] usb 5- New USB device strings: Mfr=1, Product=2, SerialNumber=3

[17802.923001] usb 5- Product: USB download gadget

[17802.923003] usb 5- Manufacturer: STMicroelectronics

[17802.923004] usb 5- SerialNumber: 003A00203438510D36383238


  1. Check U-boot device tree file is well as described in wiki, check the pin out
  2. Check hardware connections
  • If OTG controller pins are connected to a USB A/B receptacle connector or to test pins



 USB_OTG_HS_ID pin must must be left unconnected to set the STM32MP1 OTG controller as a USB peripheral . This happen if a TypeB connector is plugged-in the receptacle, PC USB wire is connected directly via test pins , ensures that the test pin is unconnected.


 USB_OTG_VBUS pin is connected to 5V. With Uboot this is needed to set internally OTG controller in "powered state".

With MP1 ecosystem < V1.X.X,  OTG-VBUS sensing can be deactivated in Uboot in the board/st/stm32mp1.c source file in board_usb_init() by setting tm32mp_otg_data.usb_gotgctl = DWC2_GOTGCTL_BVALIDOVEN |  DWC2_GOTGCTL_BVALIDOVVAL;
With MP1 ecosystem  >= V2.X OTG-HS with VBUS and ID sensing can be disabled with the follwing node in uboot dtsi file. Uboot will start OTG-HS as peripheral whatever the state of USB_OTG_HS_ID and USB_OTG_VBUS pins. 
                               dr_mode = "peripheral";      

  • If OTG controller pins are connected to a TypC Contoller to control USB_typeC receptacle

USB_OTG_VBUS , USB_OTG_pin are not used by Uboot.

A Uboot board specific code (board/st/stm32mp1.c) for the STM32MP1_DK2 board with the STUSB1600 controller to control VBUS and Role detection


  • Check PHYC regulator state

VDDA1V8_REG,VDDA1V1_REG which are the USB high-speed PHY supplies should be ON. Ensure VDD3V3_USBHS is powered by a USB supply.

When the application power tree is based on VDD=1.8V, ensure the VDDA1V8_REG is supplied by VDD (or another 1.8V supply which is present whenever USB is used) with BYPASS_REG1V8=VDD



Keyword STM32MP1 Uboot Dfu USB_OTG_VBUS STM32CubeProgrammer 

Associate III

I've fallen into this trap.

Trying to do TF-A signed binaries.

OTP is fused, device not closed.

But there is something wrong with the build? Or this just doesn't work.

I'm getting -80 (auth errors?) when trying to load bl32.

Bootrom authentication (fsbl) works ok though.

So now when I do flashing, it resets and never comes back.

I don't understand why it has to reset in the first place?

It's already in DFU mode?

Associate II

I would like to contribute a solution with respect to this issue because I think it remains current three years after this document was published. The core of the problem is that, during SD card flashing of an image with the STM32Programmer_CLI at some point, u-boot presents itself under a new identity on the the USB bus and if you are operating in a VM (specifically a VirtualBox one), that new identity may not be passed by the host to the guest. As a workaround, some posts on this forums have suggested using the programmer from Windows. This may not be an option for everyone--I refuse to go there myself!

I found out, the hard way, how to add the u-boot new identity to VirtualBox USB settings for a given VM. The "process" is follows:

  • fire up your VirtualBox VM normally.
  • make sure you can see the target device in USB DFU mode by resorting to the lsusb command from the VM.
  • initiate the normal flashing process (some shell script that resorts to STM32Programmer_CLI as applied to some TSV image description file).
  • wait for the process to timeout, most likely after slice id #3 has been programmed.
  • go back to the VirtualBox console and select the USB settings for your target VM.
  • you will be given a chance to add visibility from the devices that are currently active. Select USB download gadget and add it to the list of devices you export to the target VM.
  • go back to your target VM and reboot it.

When you're done, all your reconnect problems should be a thing of the past.


Version history
Last update:
‎2023-09-22 03:42 AM