USB descriptor request failed – [SOLVED]

Hi all,

3 pieces BP arrived yesterday, today I tried them out, I was able to flash all with the stm32duino bootloader over STlink.

– one had not-working power over USB, but blinking and seems to work over 3.3v direct supply. Solved by (re)soldering the USB pins.
– second board seems to execute correctly the loaded sketch over USB,
– the third one, however, has “Unknown USB device (Device descriptor request failed)“. Seems to execute correctly the sketch loaded over STlink, but didn’t check exactly the blink timing.

Anyone knows a hint what can I do with this? Can be fixed or I should just throw it out?

stevestrong wrote:Hi all,

3 pieces BP arrived yesterday, today I tried them out, I was able to flash all with the stm32duino bootloader over STlink.

– one had not-working power over USB, but blinking and seems to work over 3.3v direct supply. Solved by (re)soldering the USB pins.
– second board seems to execute correctly the loaded sketch over USB,
– the third one, however, has “Unknown USB device (Device descriptor request failed)“. Seems to execute correctly the sketch loaded over STlink, but didn’t check exactly the blink timing.

Anyone knows a hint what can I do with this? Can be fixed or I should just throw it out?

The USB pull-up is 10k, but all three boards have the same and the other two have working USB descriptor recognition, both DFU and CDCACM. But this one cannot get either DFU or CDCACM recognized by Win10.64b.
The 3.3V is correct and stable.

So I think it must have something to do with the USB peripheral, internal oscillator and/or internal clock for USB?
How could I evaluate whether it is good or not?

stevestrong wrote:The USB pull-up is 10k, but all three are the same and the others have working USB descriptor recognition.
The 3.3V is correct and stable.

So I think it must have something to do with the USB peripheral, internal oscillator and/or internal clock for USB?
How could I evaluate whether it is good or not?

USB clock runs off the main 72MHz clock via a divider ( of 1.5 ) to bring it down to 48MHz

If the main clock is not running at 72MHz , for example if it was 71MHz, the USB will not work.

However the problem is more likely to be that the USB D- or D+ connection are not connected.

RogerClark wrote:However the problem is more likely to be that the USB D- or D+ connection are not connected.

stevestrong wrote:…
3 pieces BP arrived yesterday, today I tried them out, I was able to flash all with the stm32duino bootloader over STlink.
… many problems described …

Rick Kimball wrote:Can you provide a link to the seller so we can avoid them ?

stevestrong wrote:Rick Kimball wrote:Can you provide a link to the seller so we can avoid them ?

@stevstrong

I’m glad you fixed it.

I’m not sure if any vendor is any worse than the others. I doubt that any the Blue Pill vendors actually test the boards, so the problem probably lies with the manufacturer.

The Baite Maple mini’s need to have the bootloader flashed somehow, which could be done before the MCU is soldered onto the board, but they may be flashing after…

Then at least they know the CPU must be getting power and also some of the GPIO connections, and they may go as far as checking that the LED flashes (but this is all conjecture)

However, I think most people’s experience is that the Maple Mini from the official “Baite online store” is that they seem to be well made, and possibly tested before the leave the factory.

Unfortunately, even with full testing and good quality control, some items arrive with the customer DOA, this can occur for a number of reasons.
A poor solder joint might appear visually OK, and conduct fine when placed in the test jig, only to fail later after the vibrations and shocks of transportation. When purchasing parts or spares of low monetary value, i usually but two or three (or perhaps 5 or 10 if the cost is very low).
This covers for the occasional failure in shipping and gives me more options if I screw up the first time.
I have only encountered a few issues with items over the years and in the majority of cases the supplier resolved them to my satisfaction.
I could go on a rant about the few who have not, but I don’t want sued by DHL, Homebase or any of the others, I simply don’t use them any more.