DFU bootloader has errors on new BlackPill F411

[david.prentice]

Thanks ag123 and mrburnette,

The BOOT0+RST behaviour seems to work just fine (for you).
You get STM32 BOOTLOADER.
With RST you get the running Application. You happen to have a CDC application.

I suggested STM32CubeProgrammer because it is a Java program that should work on Windows, Mac and Linux.
Yes, USBVIEW might be easier. It means Windows.

Whether you use a Diagnostic Program or not, you should get a healthy "Boing" for a successful USB and not a "USB failed"

I should receive my (WeAct) BlackPill on Thursday or Friday.
My "suspect" board does not have a brand name.

[ag123]

no good, it seemed even the f4xx may possibly have clones, stm32 mcus has reached record prices
viewtopic.php?p=8155#p8155

[david.prentice]

The chip "looks" genuine. I am not going to make a fuss until I see how my WeAct board behaves.

My "suspect" BlackPill seems to work fine via UART Bootloader, SWD, ...
It should be simple to compare the ROM memory between chips to see if there is an unstable section of the factory USB-DFU code.

I guess that any failings in the ARM core or peripherals will be apparent with further use.
I presume that someone, somewhere has a test-suite that detects non-ST chips.

I have always been sceptical of complex chips being cloned. It would be a lot of work and effort to create your own Silicon design. Then get them made and packaged. Even if you "stole" the design files you have to get wafers made in a foundry.
No one is going to package die failures from a Wafer.
It is far more "likely" that "some" packaged chips fail the QC process but manage to "leave" the factory. It seems a risky business model for a company.
Quite possible for individual Ebay sellers.

David.

[fpiSTM]

Just a small description of the DFU BL mode of the F411 :

F411_DFU_BL.png (68.25 KiB) Viewed 6680 times

[ag123]

@david.prentice well i'd guess you are right about it. so there are 2 possibilities.
1) qc issue on the board
2) host related signal/timing issues
don't think rivals has incentives to make 'clones' of complex chips, the simpler ones maybe yes due to the large sales volumes.

[david.prentice]

The caveat about High Speed crystals seems to apply to all the F4 devices. At least to F401, F411, F446 in AN2606 STM32 microcontroller system memory boot mode

The BlackPill has 25MHz XTAL. So USB DFU might be unreliable with any F4 devices that use a 25MHz crystal.

I suppose that I can measure the actual HSI frequency on this particular F411 BlackPill.

It looks as if I have to do some studying !!

The Nucleo-F411 enters USB-DFU bootloader just fine.
If I mounted a 25MHz XTAL on my Nucleo-F411 board could I replicate the "unreliability" ?

David.

[ag123]

this is interesting to me as well, as it did not occur to me the bootloader 'guessed' the external HSE frequency.
for luck or otherwise it seemed rather stable in my case.

[AndrewBCN]

Hi,
I have been using the STM32F411CEU6 "Black Pill" for a few months now, both original WeAct samples and copies, and I can easily get all of them in DFU mode.
There are a few rules to follow to use DFU programming:
1. Make sure to use quality USB C data cables, not more than 1.5m in length.
2. Either a) connect the USB C cable with the BOOT button pressed and after 2 seconds release it, or b) connect the USB C cable, press and hold the BOOT button, press the RST button momentarily and after 2 seconds release the BOOT button. I usually use method a).
3. Repeat step 2 a) or b) until the Black Pill enters DFU mode. Sometimes 2, 3, or more tries are needed.

In 6 months and using half a dozen different STM32F411 Black Pills, I have not had a single programming error. However, a friend of mine had to resolder the USB C connector on his STM32F401 non-WeAct Black Pill to get DFU programming to work.

Conclusion: YMMV, but in principle try to buy only the original WeAct Black Pills, as they seem to have better quality control.

[david.prentice]

My brand new WeAct V3.0 board arrived just now.

BOOT0 + RST does not start STM32 Bootloader.
Pressing KEY for 5 seconds does start STM32 Bootloader.

I select Upload method: STMCubeProgrammer (DFU)
Build and run ASCIITable.ino
This creates a "STM Serial" on COM3.
When I select COM3 and open Serial Monitor : it displays the ASCII Table

Subsequent BOOT0+RST does not start STM32 Bootloader.
Subsequent KEY does not start STM32 Bootloader.

Selecting Upload method HID Bootloader 2.2 does not start any Bootloader.

However I can use (DFU) if I unplug USB. Re-plug with MODE0 button pressed.

So it appears that BOOT0 + RST does not start STM32 Bootloader reliably. I suspect that you might succeed after 100 attempts.
And the only way to Bootload is via a power cycle.
The BluePill uploads fine with HID 2.2 (and USB CDC Serial)

No, I have not measured the HSI frequency on either BlackPill yet.

David.

[fpiSTM]

@david.prentice
Do you used a USB HUB of USB port of a docking?
I already saw issue when using it.