STM32F411CE bootloader wrong USB VID/PID ?

[PRenn.1]

When I hold BOOT0 while hitting Reset the Device boots up and configures the USB as VID/PID 0x0000/0x0002 but the STM32CubeProgrammer expects 0x0483/0xdf11.

As far as I know the bootloader is in ROM (e.g. cannot be overwritten/damaged) so how can it be that the device shows up with "wrong" USB IDs ?

[waclawek.jan]

What hardware is this? Is the STM32 connected directly to the USB connector?

> When I hold BOOT0 while hitting Reset the Device boots up and configures the USB as VID/PID 0x0000/0x0002

How do you know?

JW

[PRenn.1]

WeAct "BlackPill V3.1" board with STM32411CE.

USB Connewction to Windows 10, USB Device Tree Viewer V3.1.0

Boot0 held while resetting shows the following USB-Device :

Device ID                : USB\VID_0000&PID_0002\5&670B65E&0&3
Hardware IDs             : USB\DEVICE_DESCRIPTOR_FAILURE
Driver KeyName           : {36fc9e60-c465-11cf-8056-444553540000}\0017 (GUID_DEVCLASS_USB)
Driver Inf               : C:\WINDOWS\inf\usb.inf
Legacy BusType           : PNPBus
Class                    : USB
Class GUID               : {36fc9e60-c465-11cf-8056-444553540000} (GUID_DEVCLASS_USB)
Interface GUID           : {a5dcbf10-6530-11d2-901f-00c04fb951ed} (GUID_DEVINTERFACE_USB_DEVICE)
Enumerator               : USB
Location Info            : Port_#0003.Hub_#0001
Manufacturer Info        : (Standard-USB-Hostcontroller)
Capabilities             : 0x64 (Removable, SilentInstall, RawDeviceOK)
Status                   : 0x01806400 (DN_HAS_PROBLEM, DN_DISABLEABLE, DN_REMOVABLE, DN_NT_ENUMERATOR, DN_NT_DRIVER)
Problem Code             : 43 (CM_PROB_FAILED_POST_START)
Address                  : 3
Power State              : D3 (supported: D0, D3, wake from D0)

[waclawek.jan]

I am not expert in what windows reports, but this

> DEVICE_DESCRIPTOR_FAILURE

sounds much like the STM32F4xx does not communicate, for whatever reason.

Try to heat it up.

JW

[PRenn.1]

Physically all should be well: There seems to be a demo programm running right after reset, that dimms and brightens the LED cyclically. In that mode the USB device looks fine with STM VID (0483) and some PID 572A (read: communication/temp. should not be an issue) :

Device Description       : USB-Eingabegerät
Device Path              : \\.\usb#vid_0483&pid_572a#316937823132#{a5dcbf10-6530-11d2-901f-00c04fb951ed}
Device ID                : USB\VID_0483&PID_572A\316937823132
Hardware IDs             : USB\VID_0483&PID_572A&REV_0200 USB\VID_0483&PID_572A
Driver KeyName           : {745a17a0-74d3-11d0-b6fe-00a0c90f57da}\0000 (GUID_DEVCLASS_HIDCLASS)
Driver                   : \SystemRoot\System32\drivers\hidusb.sys (Version:   Date: )
Driver Inf               : C:\WINDOWS\inf\input.inf
Legacy BusType           : PNPBus
Class                    : HIDClass
Class GUID               : {745a17a0-74d3-11d0-b6fe-00a0c90f57da} (GUID_DEVCLASS_HIDCLASS)
Interface GUID           : {a5dcbf10-6530-11d2-901f-00c04fb951ed} (GUID_DEVINTERFACE_USB_DEVICE)
Service                  : HidUsb
Enumerator               : USB
Location Info            : Port_#0003.Hub_#0001
Location IDs             : PCIROOT(0)#PCI(1400)#USBROOT(0)#USB(3), ACPI(_SB_)#ACPI(PCI0)#ACPI(XHC_)#ACPI(RHUB)#ACPI(HS03)
Container ID             : {c673f10e-1672-5253-ba0c-6562a733129e}
Manufacturer Info        : (Standardsystemgeräte)
Capabilities             : 0x94 (Removable, UniqueID, SurpriseRemovalOK)
Status                   : 0x0180600A (DN_DRIVER_LOADED, DN_STARTED, DN_DISABLEABLE, DN_REMOVABLE, DN_NT_ENUMERATOR, DN_NT_DRIVER)
Problem Code             : 0
Power State              : D0 (supported: D0, D3, wake from D0)
 Child Device 1          : HID-konformes, vom Hersteller definiertes Gerät
  Device ID              : HID\VID_0483&PID_572A\7&F3C2821&0&0000
  Class                  : HIDClass

But I'll try and warm it up ...

[PRenn.1]

Well, seems I'm screwed http://www.efton.sk/STM32/gotcha/g125.html

Instead of cycling through some "possible" PLL mutipliers accounting for temp.drift of MSI (which would allow communiction with some fault tolerance) the STM bootloader calculates one frequency and does not care if people are using extrenal 20MHz crystals. *sigh*

[migry]

Just to add to this topic.

My friend gave me his NanoVNA, a ham radio RF device based on the STM32F072. I can't recall the conversation, but I think that he couldn't update the firmware.

Well I tried it for the first time today, and I get USB connectivity problems. The Win10 PC does not recognise the device (I have shorted the BOOT0 and VDD pads). In the device driver I see the VID of 0x0000 and PID of 0x0002 just like the original poster.

I will try reading the link in the last posting to see if it can be rescued.

Ironically some time ago I had a problem with a AVR chip, which couldn't be flashed. Eventually I figured out that the config fuses were selecting the wrong oscillator (likely my mistake during programming) and by connecting an external crystal osc, I was able to re-flash the device and it's fuses. I can confirm that this STM32F072 circuit uses no external crystal.

[waclawek.jan]

The article under link above talks specifically about USB DFU bootloader working out of crystal. In case of 'F072 - as lack of crystal indicates too -  the USB DFU bootloader works out of the Clock Recovery System (CRS)-conditioned internal oscillator, so the "heating fix" does not apply.

Given circumstances, I'd suspect USB pins damaged by high level of injected RF.

JW

[migry]

I have purchased a cheap gadget which apparently does SWD (OpenOCD programmer). The SW pins are brought out to an edge connector. I have no idea if this will work, or even what the programmer can do. Although I have familiarity with many different micros, I know virtually nothing about the STM32(*), so it will be a bit of a chance to learn. I hope that it might be possible to burn the firmware using this programmer, but I have no idea.

The original firmware is actually working. This is an open source design, and since it's release much improved versions of firmware have been released, which is why my friend wanted to connect the device to USB. Since it was "broken" he gave it to me, since I have an interest in microcontrollers and he thought that I might be able to "fix" it.

Push comes to shove I can remove the CPU and replace with a new one.

(*) Since there is no crystal on the PCB, I  assume that it must be using the internal RC oscillator, which is possible factory calibrated. Again a big guess is that the oscillator frequency might have drifted out of spec, as hinted at in the article. I did try heating up the package but with no success. The poster tells me this will make no difference, and he appears to be correct.

And yes I have been lazy. I need to thoroughly read the datasheet for this device.

Perhaps as the poster suggested the USB has been damaged, however the device is meant for low power RF purposes and even has a low power generator for measuring S21, I would be surprised if RF killed the USB, *but* you never know.

I will post an update once I have the "programmer".

[waclawek.jan]

> Since there is no crystal on the PCB, I assume that it must be using the internal RC oscillator, which is possible factory calibrated.

No. While it is indeed factory calibrated, that wouldn't suffice for USB - as I've said above, the internal RC oscillator is conditioned by the received USB signal through the CRS module.

At this point you should start your own thread, rather than hijacking this one.

JW