I want to share my stupid experience about my electronics hobby. TL;DR near the end if you just want the summary.
Two weeks ago I ordered two generic Blue Pill boards. I also ordered a USB to Serial Converter with CP2102 chip to program the Blue Pill boards.
Missing Resistor Instead of Wrong Value Resistor
Both Blue Pill boards arrived with the correct R10 resistor value of 1.5kΩ. The generic Blue Pill boards are famous that they usually have wrong R10 value, so I’m glad that mine arrived with the correct value.
However, one board arrived without resistor on R5. R5 functions as a current limiting resistor for the on-board PC13 LED. Because it is missing, now current would not even flow to the on-board PC13 LED at all. The impact was that the on-board PC13 LED would not light up. I know these boards are very cheap, but a missing resistor?! I scoured the web to see if others have similarly missing resistor on R5, but apparently I must be the only person to experience them. So I just bought a bunch of SMD 0603 (imperial) 680Ω resistor and soldered one to R5. One problem solved.
Programming the Board Using the USB to Serial Converter
After that, I ran PlatformIO and tried to program the boards using the USB to Serial Converter. Here’s what I did:
- Copied the Blink program from Arduino IDE to PlatformIO.
- Changed the
- Changed the LED on/off duration a bit, for no particular reason.
- Inverted the
LOWin the Blink program. This is because STM32F103C8 PC13 LED lights up when the pin is pulled
LOW, unlike Arduino UNO and Nano.
- Edited the
platformio.inifile to select
- Installed the PlatformIO udev rules in my computer.
- Set the board’s BOOT0 jumper pin to 1 and the BOOT1 to 0.
- Wired the Blue Pill board to the USB-to-Serial-Converter.
- Connected the USB-to-Serial-Converter to my computer.
- Compiled in PlatformIO.
- Uploaded from PlatformIO.
It worked! The on-board PC13 LED was blinking as programmed. To keep the Blink program on the board, I changed back the BOOT0 jumper pin to 0 before powering it off. This way the program will not be erased after power-off or after reset.
Initial Attempt to Flash A New Bootloader
Next I want to be able to program the board without the hassle of fiddling with the BOOT0 jumper and wiring the USB-to-Serial-Converter. I want to be able to upload program to the board just by using the on-board micro USB connector. Roger Clark’s bootloader is widely known for this purpose. So here’s what I did:
- Downloaded the latest
- Set the board’s BOOT0 jumper pin to 1 again.
- Wired the Blue Pill board to the USB-to-Serial-Converter again.
- Connected the USB-to-Serial-Converter to the computer again.
- Ran the st-flash utility to flash the bootloader binary to the Blue Pill board. There is no need to download the st-flash utility separately, because PlatformIO already downloaded it to
The flashing was complete! Now to see if the Blue Pill’s board is recognized by my computer when connected directly. Here’s what I did:
- Changed the BOOT0 to 0 again while the Blue Pill board is still connected to the USB-to-Serial-Converter and while it is still powered on.
- Unplugged the USB-to-Serial-Converter from the computer.
- Unplugged the Blue Pill board from the USB-to-Serial-Converter wires.
- Connected the Blue Pill board to the computer directly by using the Blue Pill’s onboard micro USB connector, using a USB A-Type to micro-USB B cable.
The PC13 LED lights up repeatedly, and nothing happened. Dmesg didn’t show any newly connected USB devices. I run
lsusb and saw that no LeafLabs/Maple USB device is listed. That was strange, because I read somewhere that Roger Clark’s bootloader will blink the LED to signify that it is installed. And yet the board was not detected as a USB device.
Somehow it didn’t work. I tried it several more times, even using the other Blue Pill board (I got two, remember). Nothing worked.
Next Attempt With New Board and New Upload Protocol
At that point, I suspected one or the combination of:
- The STM32F103C8 chip on these boards were fake.
- The CP2102 USB to Serial Converter was bad.
- The st-flash utility somehow didn’t work right to flash bootloader on my computer.
To address these possibilites, here’s what I did:
- Ordered one more board. This time I ordered a RobotDyn STM32F103C8 board. I specifically ordered one with STM32 chip (RobotDyn sells boards with STM32 clones as well, such as APM32), and with “Arduino bootloader” preinstalled. This bootloader is presumably the same as Roger Clarks’ bootloader.
- Ordered a ST-LINK V2 clone.
- Downloaded STMicroelectronics’ proprietary STM32CubeProgrammer.
The RobotDyn board and ST-LINK V2 clone arrived. Since the RobotDyn board was supposedly preinstalled with the “Arduino bootloader”, before doing anything, I connected it to my computer. The LED blinks repeatedly, and just like the two other Blue Pill boards, it was not detected by the computer. Strange.
So I tried the ST-LINK V2 clone and STM32CubeProgrammer, and it was detected. STM32CubeProgrammer via ST-LINK V2 clone was able to show the flash content of the RobotDyn board, the MCU register content, etc. However, when the RobotDyn board is connected directly (not using the ST-LINK V2), the computer was not detecting any new USB device. I was utterly frustated.
I tried to use the ST-LINK V2 clone with the generic Blue Pill boards, and it worked the same: board detected, flash content and MCU register accessible, etc. I disconnected the ST-LINK V2 clone again and tried to connect the RobotDyn board directly again. Utter nothing again.
I mean, come on: all three boards are not detected as USB devices?! I was beginning to think that maybe it was the computer’s USB port that’s broken. So I tried using the other USB port. Same thing. From ST-LINK V2 fine, but direct generic Blue Pill and RobotDyn board not detected.
- Programming using CP2102: worked, tried on two generic Blue Pill boards.
- Programming using ST-LINK V2 clone: worked, tried on all boards, on two different USB ports on my computer.
- But none of the boards are recognized by the computer when connected directly.
Hmm, when I say “directly”, I mean by using a USB A-Type to micro-USB B cable. I tried to remember how I got this cable. It was bundled with a rechargable flash light I bought last year. That was when it occured to me: maybeeeeeeee … this cable is the culprit.
So I tried using other known-good USB cable that I already had. The result: all three boards were now recognized by the computer.
21/05/20 21.17 kernel usb 1-1.2: Product: Maple 003
21/05/20 21.17 kernel usb 1-1.2: Manufacturer: LeafLabs
21/05/20 21.17 kernel usb 1-1.2: SerialNumber: LLM 003
So that was it. The stupid USB cable probably doesn’t even have the D+ and D- pins connected to the wires. I wasted hours and hours because of this freaking …. you know what: my own fault in not checking the simple things first. Lesson learned.
TL;DR: Check your cable.
- Thanks to the ST-LINK V2 clone, I now know that the two generic Blue Pill boards indeed have fake STM32F103C8 chip. Apparently this has been known for some time, but it was news to me. The chip actually is CS32F103C8T6, then someone erased/blacktopped the CS32 marking on the chip package and then overlaid it with STM32F103C8 marking.
- There is no problem with the The CP2102 USB to Serial Converter.
- There is no problem with the st-flash utility.
Now that I have Roger Clark’s bootloader in all three boards, I should be able to program them directly from the on-board micro USB connector using the DFU upload protocol. I haven’t tried that yet. Oh well, next time.