BlackPill V3.1 Bootmode wrong USB VID/PID

[dipr]

Hi guys,

I've just bought a BlackPill STM32F411CE Board, backside reads "V3.1 WeAct Studio".
I'd like to get the pure USB setting to work, e.g. download to board using STM32CubeProgrammer via USB-DFU, w/o need to get a ST-Link.

Supposedly one should boot into bootloader mode but that dowesn''t work as the USB device IDs appear to be wrong
(the programmer expects 0x0483/0xdf11): Pressing BOOT0 and hitting RST shuts off the blue LED , only the red power LED is illuminated and a device pops up:

Code: Select all

Device ID                : USB\VID_0000&PID_0002\6&2DDB03AB&0&1
Hardware IDs             : USB\DEVICE_DESCRIPTOR_FAILURE
Driver KeyName           : {36fc9e60-c465-11cf-8056-444553540000}\0012 (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)

Same happens when Connecting USB while holding down the boot0 button.


But initially, after connecting to USB there starts some programm that dimms and brightens the on board LED periodically
AND has USB pop up a new Device with nicer IDs so basically the board isn't dead, it just acts weird.

Code: Select all

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)

BUT ! holding down the "KEY" button for appr. 3 Seconds has an "STM-BOOTLoader" USB-Device appear, featuring the correct VID/PID,
but only for 5 Seconds, and I can't get the Programmer to connect in that short time window.

Anyone got the pure USB Programming to work with WeAct's BlackPill V3.1 ?

[BennehBoy]

I find most of the bootloaders a complete pain in the rear to use and almost always just use an st-link clone, they're very cheap.

When I _did_ use the various DFU & HID bootloaders (I did a lot of messing around on these including porting the code for them into this core - with cleanup from fred), I would hold down the key when I anticipated the compile would complete and the uploader start, a bit of timing required, and quite frustrating sometimes.

Of course that was mainly for flashed bootloaders and not the inbuilt ones, the nice thing about the flashed ones is that the core has some code in it to detect a magic sequence over serial CDC, so it starts up the bootloader code, most of the time this means no buttons to press, but I hit the problems above many times, so just abandoned them. Naturally you need some way to flash those aftermarket bootloaders onto the device... ie an st-link.

[dipr]

Great replay, thanks.
I've found a message from ST where they admit the ROM bootloader to somehow try to detect the HSE frequency caused by the external crystal using the internal RC Oscillator which is likely to fail with increasing ext. crystal frequency https://community.st.com/s/article/FAQ- ... e-USB-does .

My problem is that the WeAct Bootloader (activated by holding down "key" for > 3 seconds) does indeed switch USB to correct VID/PID (the ones STM32CubeProgramme expects) but only for 5 seconds!
So I think I have to get me a ST-Link device anyhow, and if only to program a better, custom bootloader.
That done I probably could Program using USB-DFU later one. But for that initial "correction" of the WeAct bootload ST-Link appears to be necessary. What a pity, because once I have an ST-Link I'd probably use it for uploading AND debugging.

Basically
- ST messed up clock detecting in their ROM bootloader, and
- WeAct messed up by having their 3-sec-KEY-press triggered flash-bootloader activate USB-DFU for way too short a time before resetting again,
does that sum up the situation correctly ?

[BennehBoy]

I think it probably does, yes.

It's only really an issue for developers though who are working on a tight cycle of build/upload/test, the vast majority of these devices are embedded and programmed once via SWD only, so I can see where ST's priority would lay.

[dipr]

Further googling showed STM32F411 USB-DFU upload is broken by design,
at least for Black Pill use4rs that have a 20 MHz external crystal: http://www.efton.sk/STM32/gotcha/g125.html

[dannyf]

to detect the HSE frequency caused by the external crystal using the internal RC Oscillator

it is possible to detect HSE/HSI with LSI or LSE (better). not sure how to detect HSE from HSI - if someone knows I would love to hear about it.

[dipr]

Maybe. But the STM bootloader is in ROM. Only ST can fix that and it would only work in new devices.

[dannyf]

the earlier link shows the use of LSE to detect HSE. That's doable. but LSE is often not as reliable / accurate as HSE. that might be the problem here.

[GonzoG]

It doesn't look like issue with MCU.

This looks like very common issue with those Black Pills. As UART pins are floating, board resets into Serial bootloader, not USB.
That's why you get "DEVICE_DESCRIPTOR_FAILURE" as there is no active USB device.

Connect PA9 to GND with resistor (eg. 10k) and try to reset it into DFU.

[ag123]

there is a traditional finger dance for stm32f4xx pill boards.
- press boot0 and reset
- release reset but hold boot0
- release boot0 1 sec later
that is the correct way to get into the *real* USB DFU mode, the on-chip USB DFU mode that is. it should flash with the STM32cube programmer and dfu-util etc. if this don't work, then maybe it isn't a stm32f4xx after all.

it is quite possible that 'clone' chips can be made to look like a f4xx, e.g. that it can even be cortex m0, but that if the chip designer managed to keep the io registers all in the same place, maybe it'd still work.

there are also goofy problems with usb such as a cable fault, i.e. cannot connect, and that sometimes perhaps some devices can't get a correct HSE speeds etc, accordingly the boot rom tries to guess the external crystal frequency, it may get it wrong for a crystal too far above 8 mhz.
but in these cases, you are unlikely to detect a VID/PID from the device.

for f4xx I won't bother with a custom bootloader, it takes flash memory and it takes the traditional 0x8000000 start of flash address.
and much less fuss bothering with custom bootloaders e.g. that your sketch is compiled for an incompatible address etc.
you would more than likely need a custom ld script file that specify where your sketch needs to sit and won't be 0x8000000