USB init failing for new bluepills

[f3sty]

I've recently bought two different lots of bluepills that don't work with this bootloader but they work fine with the STM32duino-bootloader, and user space USB works too. The chips are marked as STM32F103C8T6 but I'm sure they're fake just like most of the bluepills I've bought over the years. At first I thought I'd just received a bad batch, but it looks like many vendors are selling this new clone variant because I then got the same type from another seller :(

They symptoms seem to be they're just running too.... fast? On a 'good' bluepill PC13 LED flashes at ~20hz after burning the bootloader, but on these new ones it flashes at 60hz. The good bluepill receives its first SOF ~150ms after the start of enumeration, whereas the new bad one receives it 1ms after starting to wake the host. But with the STM32duino-bootloader flashed on the new bluepill instead, it too takes ~150ms too.

With STM32_HID_Bootloader both bluepills receive the SETUP and DATA0 packets from the host about 40-50ms after the first SOF, but these new bluepills never send an ACK (or any response to the SETUP). The host retries the SETUP transaction two more times without an answer, then tries 3 more times 400ms later.

Seeing as these bluepills work fine with other USB bootloaders the hardware is obviously capable of establishing a USB connection, which leads me to think there might be something in the initialization that they don't like? Any help would be appreciated, I've got a dozen of these now and I assume there's lot of other people receiving them too.

[f3sty]

bootsector's original stm32-hid-bootloader also works properly on these new bluepills.

[reepotah]

Having the same issue with Bluepills I've got few months ago and just unpacked. They get "Unknown USB Device (Device Descriptor Request Failed)" error in a couple of seconds after connecting it to PC. They look like this: LED on PC13, but it's a red led, same color as the power led.

I don't know how to check USB timings and all that, but my pills are blinking at 27Hz after flashing the bootloader.

One of them runs STLink v2 firmware just fine, also I tried STM32duino-bootloader and it also gets initialized properly.

[f3sty]

pulseview_usb.zip Here are a pair of pulseview captures of the USB init - one from a bluepill I bought a year or so ago (working), and the other from a recently purchased bluepill (non-working).
As much as it looks like a hardware issue, these new bluepills work fine with most other USB bootloaders and USB stacks.

[onolox]

I have a stm32F103CBT6 that have a problem similar to the OP, after flashing the green led stays on, it doesn't flash like it should (pressing reset or when plugged in USB green led off).

After plugging it into USB it shows in windows an problematic device under USB devices.

[dylansison]

I have a stm32F103CBT6 that have a problem similar to the OP, after flashing the green led stays on, it doesn't flash like it should (pressing reset or when plugged in USB green led off).

After plugging it into USB it shows in windows an problematic device under USB devices.

same issues here, and yes other usb bootloaders work just not this one

[aguaviva]

same issues here, and yes other usb bootloaders work just not this one

Which bootloaders work fine?

[agusting21]

@aguaviva this one works for me https://github.com/rogerclarkmelbourne/STM32duino-bootloader/tree/master/binaries

[arthurfprecht]

I have the same issue, bought two blue pill boards in different occasions, from different sellers, both with the Device Descriptor Request Failed Error. Similarly to what pelople above found, they work with the STM32duino Bootloader, and if I use the STLink to program them and use CDC, the USB also works just fine ?! The funny thing is that they pass the tests in the following tool: https://mecrisp-stellaris-folkdoc.sourceforge.io/bluepill-diags-v1.640.html So that mean they are compatible even bug-wise in some things, but not in the USB hardware. That's sad :(

[Harry1326]

please refer to: https://blog.csdn.net/es15071848238/article/details/141216773?spm=1001.2014.3001.5501

[Harry1326]

https://github.com/Harry1326/STM32F103C6T6_HID-bootloader

[Harry1326]

Having the same issue with Bluepills I've got few months ago and just unpacked. They get "Unknown USB Device (Device Descriptor Request Failed)" error in a couple of seconds after connecting it to PC. They look like this: LED on PC13, but it's a red led, same color as the power led.

I don't know how to check USB timings and all that, but my pills are blinking at 27Hz after flashing the bootloader.

One of them runs STLink v2 firmware just fine, also I tried STM32duino-bootloader and it also gets initialized properly.

https://github.com/Harry1326/STM32F103C6T6_HID-bootloader

[dylansison]

bootsector's original stm32-hid-bootloader also works properly on these new bluepills.

remembered about this issue, the code for USB for the bootsector one seems to be from the same source except more changes occurred after it split; digging into the changes promptly

at first glance, the bootsector one is a bit longer which probably means something; it was shrunk down

it’s probably too optimized somewhere if it isn’t some part of the process missing

[dylansison]

even the earliest commits of this version have the Device Descriptor Request Failed error, interesting. the first version of this and the current version of the Bootsector one looks quite similar and only have a couple differences, wonder it is something that was cut away early on and did not have much effect on operation of normal stm32s but are very impactful on these ones

bins of earlier commits in this repo show more normal speed pc13 led flickering so that might be a separate thing and not a symptom of what may be causing our USB woes here

[dylansison]

the bugs have been found (i think... or at least one of these is what caused it)... and were found by others in bootsector/stm32-hid-bootloader -> commit e3b264f and e58113c

more to do though because this version is very different now from bootsector/stm32-hid-bootloader unlike in the old version i threw new edits from the other repo into

edit: i think i mirrored the changes in the new version usb.c and hid.c; still doing DDR error so perhaps that high speed flashing does also have something to do with it

edit 2: led phenomenon occurs between serasidis a502fb0 and fa8fb65

edit 3: i was being stupid and thinking the precompiled binaries were being updated every commit but they werent, the led stops flashing at said ~25hz sometime after 85526e2...

good night

[dylansison]

notes for today:

started bisecting (TIL what git bisect is) and continued experimenting

the change made in bootsector e58113c fixes the problems in the earlier versions around serasidis 34d7d73

commit 79c474e is the first bad commit

edit 1: So when I copied and pasted most of the SystemInit() function that was removed in the bad commit into the function that replaced it, it worked. This leads me to believe that SystemInit does more than just set the system clock frequency to 72... in which it does.

[dylansison]

The function that was replaced in commit 79c474e reset the RCC register which after looking at it in STM32CubeProgrammer has a tendency to reset to unexpected values, at least on my blue pills. While I was googling stuff regarding this SystemInit() function. I read some posts about how resetting all of that wasn't necessary since they would be set to the default values on reset so i suppose real STM32F103s do that whilst ours don't

edit 1: and now its not working again, dunno what i did different 😭 and also when you think about it, if i just practically pasted the SystemInit function back into the replacement function, how is that different? am thinking of just changing it again to use the SystemInit function from CMSIS but i'm sure there was a reason why they chose to replace it in this one (likely size)

edit 2: briefly tried the new CMSIS 5 based stm32 cmsis package which similarly forgoes resetting all those values. LED blinks way slower now (~3hz) and it gives the DDR error. assuming that i'm not copying and pasting that bit of code from the function that is replaced inconsistently, it definitely has something to do with that function (though it really is odd why it doesnt have a consistent effect on the problem) i didnt define the speed at which the cpu should be set to, oops... and it seems this new thing finds the system clock frequency differently (it isn't just explicitly set by a function so it seems)

[arthurfprecht]

@dylansison Awesome work! Please let me know if I can help in any way, I have one of these boards, the debugger and so on. I will try to follow your investigation and see the behaviour on my board here.

[dylansison]

@arthurfprecht hi! it would be a big help if you could figure out what exactly in the code fixes the problem and how the code can be cut down to fit back into >=2048bytes

also wonder if this is actually consistent across both of our boards or if the USB init problems have even more causes depending on the chip

[arthurfprecht]

https://github.com/Harry1326/STM32F103C6T6_HID-bootloader

Hi @Harry1326, I tested the bootloader on my board (a F103C8) and unfortunately it does not work either, failing enumeration too 😢.

[Harry1326]

Hi，@arthurfprecht ， if you test F103C8，you just need to burn the repo of this origin bin file:https://github.com/Serasidis/STM32_HID_Bootloader/releases/download/2.2.2/stm32_binaries.zip, i have tested this file ok with F103C8 ,if you test F103C6 you can use the bin file of my: https://github.com/Harry1326/STM32F103C6T6_HID-bootloader

[Harry1326]

you can refer to my blog: https://blog.csdn.net/es15071848238/article/details/141216773?spm=1001.2014.3001.5501 use STLink or daplink burn this boot: