BMP support status for Blue Pill

[kholia]

When I flash the latest BMP master (7cb1858aca) from this repository on a Blue Pill board via ST-LINK/V2, I see the following errors after connecting the Blue Pill via USB,

$ dmesg
...
[33288.904943] usb 1-6.3.4: new full-speed USB device number 26 using xhci_hcd
[33288.981983] usb 1-6.3.4: device descriptor read/64, error -32
[33289.167968] usb 1-6.3.4: device descriptor read/64, error -32
[33289.351919] usb 1-6.3.4: new full-speed USB device number 27 using xhci_hcd
[33289.428979] usb 1-6.3.4: device descriptor read/64, error -32
[33289.607981] usb 1-6.3.4: device descriptor read/64, error -32
[33289.715143] usb 1-6.3-port4: attempt power cycle
[33290.318943] usb 1-6.3.4: new full-speed USB device number 28 using xhci_hcd
[33290.319103] usb 1-6.3.4: Device not responding to setup address.

Here are my build and flash steps,

$ git clone git@github.com:blacksphere/blackmagic.git

$ make clean && make PROBE_HOST=swlink  # stlink results in the same problem

$ st-flash erase

$ st-flash write src/blackmagic_dfu.bin 0x8000000

$ st-flash --flash=0x20000 write src/blackmagic.bin 0x8002000

I am running Ubuntu 18.04 LTS 64-bit here.

In comparison, when I flash the pre-built binaries available on stm32duino forums, the same Blue Pill board connects just fine over USB.

These binaries were built from https://github.com/UweBonnes/blackmagic (bluepill branch which is now gone). Was the functionality present in this fork ever merged to this repository? If yes, has a regression been introduced in the current state of this repository?

Thanks for the help.

CC @UweBonnes.

Update: The binaries from http://builds.blacksphere.co.nz/blackmagic/ also have problems with USB.

[UweBonnes]

Was the USB pullup changed to 1.5 k? I will try with one of my bluepill boards the next day, as time allows.

[kholia]

I haven't changed the pull-up resistor (R10 IIRC) yet. I haven't handled SMD desoldering/soldering before :)

I suspect that the old blackmagic_dfu.bin (from stm32duino forums) had a software hack which sort of avoids the need to change this pull-up resistor?

There is something "unique" about that old blackmagic_dfu.bin file.

Thanks!

[UweBonnes]

I don't think the old branch did that. Perhaps add that hack, test and on success add to master with a pull request.

[UweBonnes]

I did a test on a bluepil board and flash it via SWD and after un- and replug it enumerated. Please recheck your setup.

[kholia]

Thanks!

I have validated and reproduced this issue on multiple Blue Pill boards (one of them even has a clone STM32 chip!).

• When I flash that old blackmagic_dfu.bin file, USB stuff works great (all boards are enumerated nicely).

• When I flash self-compiled blackmagic_dfu.bin, none of the boards get enumerated.

Questions:

• Could it be that I am missing something simple when compiling these binaries? I have pasted my build steps above.

• To narrow down this a bit, can you please attach your blackmagic_dfu.bin (Update: and blackmagic_dfu) files built from the latest git master? I can diff yours against mine.

[UweBonnes]

Bin upload is not supported here and zip upload give "Somethinh went really wrong". Drop me your mail address on the private gitter channel..

[kholia]

To work around this limitation, I append a .txt extension to the ZIP file to be uploaded.

[hierophect]

@kholia If you don't mind me asking, how are you even flashing a bluepill using texane/stlink? The texane code doesn't support writing to the full 128kb on a bluepill, does it? I get the usual flash write errors whenever I try.

[kholia]

Checkout https://github.com/kholia/Arduino_Core_STM32/blob/master/Notes.md.

Update: I am even working with one clone CS32F103C8T6 based board just fine ;(

[hierophect]

Unfortunately I don't understand how your instructions can work either - blackmagic-swlink.bin is still 74kb... It won't fit on a bluepill. How long ago did you put those notes together? Is it possible that it was smaller at time of writing?

[kholia]

These notes are from April / May 2019.

"Most" of the STM32F103 boards actually have 128 KB of flash. All (~10) of my boards do, including the one with that clone STM32 chip.

[hierophect]

@kholia yes, I know. But I am confused as to how you were using st-link and dfu-util for your flashing, because neither of them support flashing past the announced size of the chip by default, which the bluepill will report as 64kb.

I've since recompiled st-link with a hack to get around the restriction, and you can use /scripts/stm32_mem.py instead of dfu_util as we've been discussing in #471, but I still don't understand how your notes could be working as described with a binary over 64kb. Both of those programs should throw a memory write error with the syntax you've given. If you are modifying either program, or using an old low-size binary release, perhaps you could mention that?

[kholia]

The notes should work as they are when followed in a verbatim fashion. Have you tried the steps without changing them? Did you run into any specific problems?

Give them a try.

[hierophect]

Yes, I ran your steps verbatim, and they produced write errors. st-link requires a modified recompile to handle larger-than announced flash sizes. dfu_util also fails (I haven't attempted to edit it). The specific problem is that these programs will not attempt to flash binaries larger than what the chip reports it has, and the C8T6 will report 64kb max. Are you sure you are using a C8T6, and not a CBT6?

(I don't mean to be rude by the way, as I've solved this issue for a while, I'm just hoping to help with your instructions as I'm not sure how they'd work for anyone as written)

[outblasted]

TL;DR: if a prebuilt blackmagic_dfu.bin works, but a hand-built binary doesn't, consider building with toolchain from developer.arm.com -- the default toolchain distributed with your system may be broken.

Hi, @kholia, all,

I've stumbled upon a similar issue.

When I flash pre-compiled blackmagic_dfu.bin from stm32duino.com, my computer identifies USB device as follows:

$ dmesg
new full-speed USB device number 58 using xhci_hcd
New USB device found, idVendor=1d50, idProduct=6017
New USB device strings: Mfr=1, Product=2, SerialNumber=3
Product: Black Magic (Upgrade) for Bluepill, (Firmware v1.6-rc0-453-g10b274a-dirty)
Manufacturer: Black Sphere Technologies
SerialNumber: E0DCBEBD

However, when I build blackmagic_dfu.bin myself via make PROBE_HOST=swlink and flash it, it doesn't work:

$ dmesg
new full-speed USB device number 45 using xhci_hcd
Device not responding to setup address.
Device not responding to setup address.
device not accepting address 45, error -71

Knowing that the board is capable of initializing USB properly, I wanted to test existing OpenCM3 usb examples, and discovered this issue: stm32f1-h103 usb examples not working. The problem there was that some toolchain was broken, but arm toolchain worked fine.

After I have downloaded and installed the toolchain from developer.arm.com, rebuilt blackmagic_dfu.bin and flashed it, the board got identified as follows:

$ dmesg
new full-speed USB device number 59 using xhci_hcd
New USB device found, idVendor=1d50, idProduct=6017
New USB device strings: Mfr=1, Product=2, SerialNumber=3
Product: Black Magic (Upgrade), SWLINK, (Firmware v1.6.1-278-g589d297)
Manufacturer: Black Sphere Technologies
SerialNumber: E0DCBEBD

My hardware details: I have a generic blue pill board that matches description at https://wiki.stm32duino.com/index.php?title=Blue_Pill, with 128k flash. It came with R10 = 10k, and I had to replace it with 1.5k to get USB to work.

Hope this helps.

[kholia]

It came with R10 = 10k, and I had to replace it with 1.5k to get USB to work.

Thank you!

I haven't replaced R10 (yet) and the pre-compiled blackmagic_dfu.bin from stm32duino.com works just fine with my boards (just one more data point / observation).

I will try that toolchain soon.

[kholia]

Update: I built BMP with the GCC toolchain that comes with Ubuntu 20.04 LTS and the problem is gone now.

[UweBonnes]

It seems there are broken toolchains aut there.