Uploading fails with STM32 "Blue Pill" Board

21

The “maple_upload” tool is contained in the tool-stm32duino package. Do you have

ls ~/.platformio/packages/tool-stm32duino

? Is the maple_upload binary or script executable? On Windows, it’s a batch script.

22

Thanks! There’s no tool-stm32duino package installed. I’ve got something strange. First,

> pio pkg search tool-stm32duino
Found 1 packages (page 1 of 1)

platformio/tool-stm32duino
Tool • 1.0.2 • Published on Tue Oct 22 13:45:45 2019
STM32Duino Tools

On the other hand:

> pio pkg install -l "platformio/tool-stm32duino"
Resolving bluepill_f103c8 dependencies...
Library Manager: Installing platformio/tool-stm32duino
UnknownPackageError: Could not find the package with 'platformio/tool-stm32duino' requirements for your system 'linux_x86_64'

What is it?

PS It looks like all the software involved was last updated six years ago or something like that. Maybe today another approach to uploading is recommended? Sorry, I’m a newbie and any hint will be appreciated!

23

It’s not a library, it’s a tool. You would need

pio pkg install -g -t "platformio/tool-stm32duino"

to globally install that tool. Although really it should have already been installed by the ststm32 platform…

24

Thanks, the tool got installed. Unfortunately, the same error persists:

Uploading .pio/build/bluepill_f103c8/firmware.bin
sh: line 1: maple_upload: command not found
*** [upload] Error 127

Here’s my list of installed packages:

~/.platformio/packages> ls
framework-arduinoespressif32  toolchain-xtensa-esp32  tool-mkfatfs     tool-scons
framework-arduinoststm32      tool-dfuutil            tool-mklittlefs  tool-stm32duino
framework-cmsis               tool-dfuutil-arduino    tool-mkspiffs    tool-stm32flash
toolchain-gccarmnoneeabi      tool-esptoolpy          tool-openocd
~/.platformio/packages>
25

Oh crazy, this might actaully be a bug.

A commit in April removed the usage of the tool-stm32duino package in favor for the tool-stm32flash package.

https://github.com/platformio/platform-ststm32/commit/4b5ff01c8f91f1a2fd441c593aedfb81aa465f0f

But, that package only contains stm32flash.exe and no replacement for maple_upload, which the builder scirpt is still expecting.

So what you actually need to do for now is to go back one version. In your platformio.ini, set the platform as

platform = ststm32@19.1.0

since 19.2.0 contains the bug.

26

I downgraded the platform. Now it just hangs here:

CURRENT: upload_protocol = dfu
Looking for upload port...
Auto-detected: /dev/ttyACM0
Uploading .pio/build/bluepill_f103c8/firmware.bin

FWIW:
Before downgrading, I checked the file:

~> locate maple_upload
/home/alexey/.arduino15/packages/STMicroelectronics/tools/STM32Tools/2.3.0/maple_upload.sh
/home/alexey/.platformio/packages/tool-stm32duino/maple_upload
~> which maple_upload
maple_upload not found

Could it be just a trouble with PATH?

27

Maybe. It’s probably an oversight that the command only uses maple_upload and not the full path to the PlatformIO package in ~/.platformio. Does doing project task → Advanced → Verbose Upload reveal any more information?

The device is showing up via lsusb and you have the udev rules installed so PlatformIO / the regular user can actually access the device?

28

Actually, I use Neovim; so I’m limited to the command line. pio run -t upload -v is verbose indeed, but doesn’t offer anything new. pio run -t upload output:

CURRENT: upload_protocol = dfu
Looking for upload port...
Auto-detected: /dev/ttyACM0
Uploading .pio/build/bluepill_f103c8/firmware.bin
No DFU capable USB device found
dfu-util 0.7

Copyright 2005-2008 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2012 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to dfu-util@lists.gnumonks.org

Filter on vendor = 0x1eaf product = 0x0003
Waiting for /dev/ttyACM0 serial...Done
=================================== [SUCCESS] Took 8.85 seconds ===================================

[SUCCESS] is obviously wrong, and I have to reinstall the bootloader afterwards. The meaning of No DFU capable USB device found is unclear to me.

Udev rules are installed:

/usr/lib/udev/rules.d/99-platformio-udev.rules

The project application is valid because I can successfully load it with stlink.

29

Mhm, I’m not seeing some of the output it should have produced. Usually when the bootloader starts and it opens the

Bus 001 Device 015: ID 1eaf:0004 Leaflabs Maple serial interface

device, the maple uploader connects to that serial device and asserts the (virtual) DTR serial control line, which then causes the device to reappear as the actual 1eaf:0003 DFU USB device which is flashed.

The uploader should print something like

Resetting to bootloader via DTR pulse
Searching for DFU device [...]
Found it!
  1. Can you earse the flash of the STM32 again and put the bootloader_only_binaries/generic_boot20_pc13.bin on it again at 0x8000000
  2. Does it work then?
  3. When you look into sudo dmesg, are there logs of a 1eaf:0003 device ever showing up?
  4. When you use this Python script on your /dev/ttyACM0 port, does the 1eaf:0003 device show up?
Maple serial port to bootloader resetter py 
#!/usr/bin/env python3
import serial
import time

# Change this to your actual port
PORT = '/dev/ttyACM0'

# Open the serial port
ser = serial.Serial(PORT)

# Toggle DTR/RTS as per the Java logic
ser.rts = False
ser.dtr = False
ser.dtr = True
time.sleep(0.05)  # 50 milliseconds
ser.dtr = False

# Magic number sequence
ser.rts = True
ser.dtr = True
time.sleep(0.05)
ser.dtr = False
time.sleep(0.05)
ser.write(b'1EAF')
time.sleep(0.05)

# Close the port
ser.close()

I also notice that you don’t use the Maple core in your platformio.ini (docs), which means you’ll use the Arduino_Core_STM32, but there you also forgot to enable the CDC serial (docs). So, once the firmware loads, you will lose the USB port again and will have to press the reset button on the board to get into the bootloader again.

30

I tried all your suggestions; the result is more or less the same. Let’s clear it one at a time. I understand that the 1eaf:0003 thing must show before any build or application upload. I named your Python script for /dev/ttyACM0 leaf.py.

First plugging in after uploading the bootloader:

~/spaces/cpp/BluePillBlinkyIO> ls /dev/ttyA*
/dev/ttyACM0

First run takes about 15 seconds, no console output; second run looks funny:

~/spaces/cpp/BluePillBlinkyIO> ./leaf.py
~/spaces/cpp/BluePillBlinkyIO> ./leaf.py
Traceback (most recent call last):
  File "/home/alexey/spaces/cpp/BluePillBlinkyIO/./leaf.py", line 13, in <module>
    ser.rts = False
    ^^^^^^^
  File "/usr/lib/python3.13/site-packages/serial/serialutil.py", line 463, in rts
    self._update_rts_state()
    ~~~~~~~~~~~~~~~~~~~~~~^^
  File "/usr/lib/python3.13/site-packages/serial/serialposix.py", line 708, in _update_rts_state
    fcntl.ioctl(self.fd, TIOCMBIC, TIOCM_RTS_str)
    ~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
OSError: [Errno 71] Protocol error
exit 1
~/spaces/cpp/BluePillBlinkyIO>

~/spaces/cpp/BluePillBlinkyIO> sudo dmesg | grep 1eaf
[ 6654.911292] usb 1-10.4: New USB device found, idVendor=1eaf, idProduct=0003, bcdDevice= 2.01
[ 6656.710284] usb 1-10.4: New USB device found, idVendor=1eaf, idProduct=0004, bcdDevice= 2.00
[13818.178657] usb 1-10.4: New USB device found, idVendor=1eaf, idProduct=0003, bcdDevice= 2.01
[13819.962617] usb 1-10.4: New USB device found, idVendor=1eaf, idProduct=0004, bcdDevice= 2.00
[14320.664525] usb 1-10.4: New USB device found, idVendor=1eaf, idProduct=0003, bcdDevice= 2.01
[14322.453653] usb 1-10.4: New USB device found, idVendor=1eaf, idProduct=0004, bcdDevice= 2.00
[54214.006711] usb 1-10.4: New USB device found, idVendor=1eaf, idProduct=0003, bcdDevice= 2.01
[54215.806558] usb 1-10.4: New USB device found, idVendor=1eaf, idProduct=0004, bcdDevice= 2.00
[54865.539702] usb 1-9: New USB device found, idVendor=1eaf, idProduct=0003, bcdDevice= 2.01
[54867.381675] usb 1-9: New USB device found, idVendor=1eaf, idProduct=0004, bcdDevice= 2.00
[85137.790980] usb 1-10.4: New USB device found, idVendor=1eaf, idProduct=0003, bcdDevice= 2.01
[85139.596970] usb 1-10.4: New USB device found, idVendor=1eaf, idProduct=0004, bcdDevice= 2.00
[86611.947726] usb 1-10.4: New USB device found, idVendor=1eaf, idProduct=0003, bcdDevice= 2.01
[86613.806704] usb 1-10.4: New USB device found, idVendor=1eaf, idProduct=0004, bcdDevice= 2.00
[87273.386514] usb 1-10.4: New USB device found, idVendor=1eaf, idProduct=0003, bcdDevice= 2.01
[87275.176485] usb 1-10.4: New USB device found, idVendor=1eaf, idProduct=0004, bcdDevice= 2.00
~/spaces/cpp/BluePillBlinkyIO>

I understand this means trouble, and should be solved before anything else…

31

Looking at all the troubles I have had with my board, which eventually turned out to be caused by a fake board, I am wondering whether you have ruled out the possibility that you also got a fake board?

32

Good point. I can try it with Arduino IDE and HID. Is it a proof enough if it works?

UPD

Arduino IDE with HID bootloader is working out of the box.

33

Today I can tell you even more: HID bootloader is good for PlatformIO, too. As well as for Arduino IDE.

36

The issue has already been discussed on the project’s GitHub and resolved. For now, the developer branch should be used to avoid issues with Maple uploads.

must have the following platformio.ini
PD: It is recommended to first go to Pio Home in the platforms section and delete everything related to ST STM32

[env:bluepill_f103c8]
platform = https://github.com/platformio/platform-ststm32.git
board = bluepill_f103c8
framework = arduino
upload_protocol = dfu