I’m new to this forum and quite new to arduino.
I’ve brought a STM32F103C8T6 (“blue pill” with yellow headers/pins).
Plugging it to usb, it has the led blinking but the usb is not recognized. On Windows 8 i get an yellow mark on Device Manager with the error:
Windows has stopped this device because it has reported problems. (Code 43)
A request for the USB device descriptor failed.
[22329.016155] usb 6-2: new full-speed USB device number 2 using uhci_hcd
[22329.136129] usb 6-2: device descriptor read/64, error -71
[22329.360163] usb 6-2: device descriptor read/64, error -71
[22329.780160] usb 6-2: new full-speed USB device number 3 using uhci_hcd
[22329.900143] usb 6-2: device descriptor read/64, error -71
[22330.124160] usb 6-2: device descriptor read/64, error -71
[22330.340124] usb 6-2: new full-speed USB device number 4 using uhci_hcd
[22330.752130] usb 6-2: device not accepting address 4, error -71
[22330.864152] usb 6-2: new full-speed USB device number 5 using uhci_hcd
[22331.280162] usb 6-2: device not accepting address 5, error -71
[22331.280259] hub 6-0:1.0: unable to enumerate USB device on port 2
Main option is to install the stm32duino bootloader; for blue pills I think you should use this file: https://github.com/rogerclarkmelbourne/ … 0_pc13.bin
You can install it either via ST-link or via USBtoSerial adapter.
Once installed the bootloader, the PC should be able to recognize you blue pill as a DFU device and you can then upload your sketches.
Once uploaded a sketch, your PC will then be able also to recognize your blue pill as a COM device.
Search the forum for further details.
Best, E.
You will need to connect a USB-Serial adapter and flash a bootloader using the STM32 demonstrator utility before the serial port will enumerate. Then you can upload with the IDE.
using stm32flash i can write generic_boot20_pc13.bin
C:\Users\Petronel\Downloads\stm32flash-0.5-win64>stm32flash.exe -w ..\generic_boot20_pc13.bin COM9
stm32flash 0.5
http://stm32flash.sourceforge.net/
Using Parser : Raw BINARY
Interface serial_w32: 57600 8E1
Version : 0x22
Option 1 : 0x00
Option 2 : 0x00
Device ID : 0x0410 (STM32F10xxx Medium-density)
- RAM : 20KiB (512b reserved by bootloader)
- Flash : 128KiB (size first sector: 4x1024)
- Option RAM : 16b
- System RAM : 2KiB
Write to memory
Erasing memory
Wrote address 0x08010000 (100.00%) Done.
stm32flash 0.4
http://stm32flash.googlecode.com/
Using Parser : Raw BINARY
Interface serial_w32: 230400 8E1
Version : 0x22
Option 1 : 0x00
Option 2 : 0x00
Device ID : 0x0410 (Medium-density)
- RAM : 20KiB (512b reserved by bootloader)
- Flash : 128KiB (sector size: 4x1024)
- Option RAM : 16b
- System RAM : 2KiB
Write to memory
Erasing memory
Wrote address 0x08000100 (3.40%)
Wrote address 0x08000200 (6.80%)
Wrote address 0x08000300 (10.20%)
Wrote address 0x08000400 (13.60%)
Wrote address 0x08000500 (16.99%)
Wrote address 0x08000600 (20.39%)
Wrote address 0x08000700 (23.79%)
Wrote address 0x08000800 (27.19%)
Wrote address 0x08000900 (30.59%)
Wrote address 0x08000a00 (33.99%)
Wrote address 0x08000b00 (37.39%)
Wrote address 0x08000c00 (40.79%)
Wrote address 0x08000d00 (44.18%)
Wrote address 0x08000e00 (47.58%)
Wrote address 0x08000f00 (50.98%)
Wrote address 0x08001000 (54.38%)
Wrote address 0x08001100 (57.78%)
Wrote address 0x08001200 (61.18%)
Wrote address 0x08001300 (64.58%)
Wrote address 0x08001400 (67.98%)
Wrote address 0x08001500 (71.38%)
Wrote address 0x08001600 (74.77%)
Wrote address 0x08001700 (78.17%)
Wrote address 0x08001800 (81.57%)
Wrote address 0x08001900 (84.97%)
Wrote address 0x08001a00 (88.37%)
Wrote address 0x08001b00 (91.77%)
Wrote address 0x08001c00 (95.17%)
Wrote address 0x08001d00 (98.57%)
Wrote address 0x08001d6c (100.00%) Done.
Starting execution at address 0x08000000... done.
You will only see a libusb device . Not a Serial device after the bootloader first runs, The Serial USB code is in the sketch, the bootloader only contains a DFU device.
You also need to load the windows drivers ( assuming you are running windows) . Please read the FAQ in the Welcome / FAQ section
I think you told that the LED does not blink.
For this, please check which pin is assigned to LED in your sketch. The LED pin should be defined somewhat like:
#define LED_PIN PC13
Please use the “PC13” notation, not just numbers (13).
As long as you get “Hello world” on your serial monitor it means the serial communication works.
Lots of people think the bootloader is not working because they dont have a Serial USB device after it first installs.
I should merge a “blink and count” sketch with the bootloader, then everybody would be less confused. 
Perhaps the OP has a hardware fault on the USB. As the Blue pill often has broken connections to the usb data pins.
I have 2 Blue pill boards, but neither work, now, as the USB connections broke and its hard to repair without connecting an external USB socket, or perhaps solder on a cable with a plug
#define pinLED PC13
void setup() {
Serial.begin(9600);
Serial.println("start");
}
void loop() {
digitalWrite(pinLED, HIGH);
delay(500);
digitalWrite(pinLED, LOW);
Serial.println("Hello World2");
delay(100);
}
Insert to setup() the following line:
pinMode(pinLED, OUTPUT);
forgot about that. THANKS !!!
Now i noticed that the F macro doesn’t work
Serial.println(F("test"));
I’m not sure why the F macro doesnt work any more.
But I agree its now crashing if I try to use it
Actually, the F macro is not needed for ARM dev at all, and should be removed wherever possible
Looks like F is defined in WString.h
#define F(string_literal) (reinterpret_cast<const __FlashStringHelper *>(PSTR(string_literal)))
#define F(x) x
SPI.beginTransaction(CHIP_SEL, SPISettings(SPI_CLOCK_DIV4, MSBFIRST, SPI_MODE0));#define RST_PIN PA0 // Configurable, see typical pin layout above
#define SS_PIN PA1 // Configurable, see typical pin layout above
MFRC522 mfrc522(SS_PIN, RST_PIN); // Create MFRC522 instance
Found my problem with the bootloader:
I was using Flash Loader Demonstrator, and instead of “Download to device” I was using “Upload from device” , probably didn’t read to / from.
So I’ve overwrite the generic_boot_pc13.bin with the one that was on device 
Now i see the DFU I upload my sketch and after it reset I get a Maple Serial.
I agree. The terminology used is confusing.
I have 2 other questions now:
1. After a sketch is uploaded and the STM32 is resetting, the Serial connection drop for a second, and I have to close/open the Serial Monitor. Is that normal ?
2. Uploading a sketch that compile ok but crash when running (like my test with RFID) make the DFU / com disappear and getting again “Unknown device”. I can still reset the STM32 and upload an working sketch.
I have 2 other questions now:
1. After a sketch is uploaded and the STM32 is resetting, the Serial connection drop for a second, and I have to close/open the Serial Monitor. Is that normal ?
2. Uploading a sketch that compile ok but crash when running (like my test with RFID) make the DFU / com disappear and getting again “Unknown device”. I can still reset the STM32 and upload an working sketch.
Trying to use the RFID RC522 with my STM32F103.
You can also get STLink clones really cheaply, but I think you’d need to use OpenOCD to use them
Either way, using GDB from the command line takes a bit of getting used to.
Otherwise you’d need to use Eclipse + the Arduino plugin, to get a nice UI for debugging.
Its probably easier just to comment out code and use Serial.print to work out whats going wrong
You can also get STLink clones really cheaply, but I think you’d need to use OpenOCD to use them
Either way, using GDB from the command line takes a bit of getting used to.
Otherwise you’d need to use Eclipse + the Arduino plugin, to get a nice UI for debugging.
Its probably easier just to comment out code and use Serial.print to work out whats going wrong
Its probably easier just to comment out code and use Serial.print to work out whats going wrong
I think the master Blackmagic probe repo now has good support for the nRF51 but I think when Rick took his original fork of the BMP the nRF51 support was minimal
Although I still have my modified fork of the BMP based on Ricks fork + my changes for nRF51, I’m now trying to migrate back to the official master repo by Blacksphere as its loads of commits and bug fixes ahead of my fork (and also ahead of Ricks fork)
The problem is that I can’t simply merge from the Blacksphere master as the API structure of the “platform” code has changed.
So my long term plan is to remake Rick’s version for the BluePill and send a PR to add it to the Blacksphere master repo
However, I’ve been too busy recently with the official STM32 core, and also some urgent commercial work that I had to get to grips with.
We could add a wiki page for the current state of play, mainly linking to Rick’s repo for use on the STM32, we can always update it when I finally get around to re-making the BluePill platform version etc
Its probably easier just to comment out code and use Serial.print to work out whats going wrong
where is the SPI.beginTransaction() called? Within the MFRC522::PCD_Init()? I cannot see where. Or do you call it separately?
Did you set the appropriate mode for all the used pins?
