PlatformIO Community

STM32F103VG XL-Density

Development Platforms
#1

Hi,
I’ve built a custom PCB board using the STM32F103VG. The board has been debugged and is working from a hardware point of view.
I’ve attached the platformio.ini file below, along with the USB upload errors.

The issue I’m having is I am unable to upload code to it via the USB port (dfu or serial), I have to use the STLink. However the USB interface is working as I can use it to debug the board and I can see Serial.print(" text…"); via terminal on it.

From what I understand platformio uploads a bootloader to it over the stlink interface so there is no need to download the bootloader from STM. or bother about the boot0 or boot1. At least that’s what happened with the bluepill I originally tested. However, I have tested the STM bootloader and it didn’t work either. I have also tried a variation of the BOOT jumpers.

I’m now thinking the “VG” version of this MCU is classed as XL-density and I’m not sure if the memory areas are mapped differently causing some issues in USB interface on platformio.

The usb port does show up as a com port on the PC

platformio.ini

[env:genericSTM32F103VG]
platform = ststm32
board = genericSTM32F103VG
framework = arduino
board_build.mcu = stm32f103vg
board_build.f_cpu = 72000000L

;upload_protocol = stlink
upload_port = COM3
upload_protocol = serial

build_flags = 
    -w
    -D PIO_FRAMEWORK_ARDUINO_ENABLE_CDC
    -D USBCON
    -D USBD_VID=0x0483
    -D USBD_PID=0x5740
    ;-D USB_MANUFACTURER="Unknown"
    -D USB_PRODUCT="\"BLUEPILL_F103C8\""
    -D HAL_PCD_MODULE_ENABLED
    -D ENABLE_HWSERIAL1
    -D ENABLE_HWSERIAL2

Response when trying to upload via USB / Serial

CURRENT: upload_protocol = serial
Looking for upload port...
Use manually specified: COM3
Uploading .pio\build\genericSTM32F103VG\firmware.bin
stm32flash 0.4
Failed to init device.
http://stm32flash.googlecode.com/
Using Parser : Raw BINARY
Interface serial_w32: 115200 8E1
*** [upload] Error 1

Response when trying to upload via USB / dfu

Use manually specified: COM3
Uploading .pio\build\genericSTM32F103VG\firmware.bin
maple_loader v0.1
Resetting to bootloader via DTR pulse
Searching for DFU device [0483:DF11]...
dfu-util - (C) 2007-2008 by OpenMoko Inc.
Couldn't find the DFU device: [0483:DF11]
#2

Then something may be wrong in hardware after all.

Connect / jumper BOOT0 to VCC and BOOT1 to GND, connect the board via USB to the computer and prerss the reset button of the board. Does a new USB device appear in the device manager with “DFU” in the name?

grafik

If there is such a device, check its PID and VID in the settings.

grafik

If it’s not the wanted PID=0483, VID=DF11, something is wrong, re:

If no device appears at all, the USB connection to the device is broken or the jumpers have no effect on the actual voltage of Boot0/Boot1.

If a device appears in the device manager but it fails to find a driver, you need to install them, e.g. through https://www.st.com/en/development-tools/stm32cubeprog.html.

If you use STM32CubeProg you can also very quickly test whether it’s really a PIO issue or not, since you can do both USB DFU and serial uploads there. With “USB” as connection method, it should find your chip if the drivers are correct.

grafik

#3

Thanks for the response and screen shots.
when boot 0 is VCC and BOOT 1 is GND I get an error in the USB devices, with some odd PID & VID

Screenshot (19)

This is a bit odd as I’m definitely getting data from the USB on COM3 when the code is running on the MCU.
The Cube Programmer, can’t see it in this state either.

#4

When the MCU is running the firmware for a USB-CDC (=Serial) it enumerates as another USB device and another driver is loaded, so it can well be possible that this works but not the DFU mode.

Your screenshot highly suggests that something is wrong with the USB drivers and not the USB connection / wireup / hardware itself (especially if USB CDC works). This problem with “ambiguous match” also seems to be referenced in https://community.st.com/s/question/0D50X00009XkXagSAF/dfu-usage-with-stm32cbeprogrammer …maybe another USB DFU driver for an other microcontroller interferes.

Can you use https://zadig.akeo.ie/ to try and find the USB DFU device and load libusbk drivers for it?

Also, does the controller maybe draw a huge startup current when connected to USB? Are the loads somehow disconnectible or can the device be connected to a direct USB port on the motherboard / front panel instead, instead of a e.g. hub? (Or use a powered-hub)

#5

Thanks i’ll take a look at that thread to see if I can get to the bottom of it.
The board is MCU board is powered by a separate supply , im only using D-, D+ & GND on the USB.
I’m wondering if there is an issue with the low level code on the MCU as I should be seeing a VID of 0483 and PID of 0xDF11 for the DFU as that’s STMs IDs.

#6

Another quick thing to check would be the serial bootloader route. If your chip is booted in bootloader mode properly with B0=VCC, B1=GND, then it also executes the serial bootloader. Hooking up the USB-Serial adapter’s TX line to PA10 and the RX line to PA9 and GND to GND of the MCU should make it possible to test it with just STM32CubeProgrammer set to “UART” and a firmware.bin from your PlatformIO project’s .pio\build\<env> folder. That also sanity-checks if the chip is really in bootloader mode properly.

#7

I’ve recently read the documentation in a bit more detail and discovered that the MCU I’m using does not support DFU mode on USB in boot mode. The STM32F10xxx part only supports native bootloader on USART1