Hi,
After resintalling VSCode/PlatformIO the following message appeared, preventing the upload :
.platformio/packages/tool-stm32duino/maple_upload: line 29: /home/xxxxxxxx/.platformio/packages/tool-stm32duino/upload-reset: No such file or directory.
Looking in the directory in question, the file is there.
.
Thank you for your help.
Regards,
RJM
I’m guessing from the path format/screenshot visual that this is on linux?
So I noticed the same thing earlier when checking out a STM32 issue… but didn’t think anything of it as wasn’t uploading anything at the time.
Can you run the following command (file ~/.platformio/packages/tool-stm32duino/upload-reset) and see if you get similar output?
/home/pfeerick/.platformio/packages/tool-stm32duino/upload-reset: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-, for GNU/Linux 2.6.24, BuildID[sha1]=dc8dc5ad6de94179a9d534b1a34aeb6d906640b1, not stripped
I’m thinking it’s the wrong architecture… is your install 64bit? (e.g. uname -a)
Linux ubuntu-hyperv 4.15.0-54-generic #58-Ubuntu SMP Mon Jun 24 10:55:24 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
I suspect this issue is related, but not quite the right description.
Hi Peter,
Here is the output I get :
"Almost the same : sole difference is “ld-” is, in my case, “ld-linux.so.2”.
Looking forward to your reply.
Regards,
René
Hi Peter,
Any follow-up on this glitch ?
Thanks,
Regards,
Rene-Jean
Sorry, yes. It looks like the 32 libs are missing on Ubuntu … so there’s two options…
running sudo apt-get install lib32z1 (and perhaps a sudo apt update && sudo apt dist-upgrade afterwards won’t hurt), which should allow the existing 32 bit executable to run as is.
alternately, recompiling the executable as 64bit… since that folder is supposed to be for 64bit linux. I’ll do a PR for that after I’ve tested the file still works… as the original fault comes from roger clark’s repo… as it looks like he he missed just that one executable when porting to 64bit linux… 
Anyway, to do this (first make sure you have gcc installed… I prefer sudo apt install build-essential to make sure that stuff is present)
cd ~/.platformio/packages/framework-arduinoststm32-maple/tools/linux64
mv upload-reset upload-reset-32
cd src/upload-reset
gcc -o ../../upload-reset upload-reset.c
Then to test it…
cd ../..
./upload-reset
e.g.
Hi Peter,
Thank you so much. Indeed it should be included in the next release.
I got a carbon copy of your screenshot at the execution.
Thank you so much for your help.
Regards,
Rene-Jean
Glad I could help, and thanks for the confirmation… Now just need to make sure it does the reset, and I’ll see if we can get that fixed 
Hi Peter,
I have now another issue. I cannot get access to the port to communicate. Here is what I can report.
The VSCode/PlatformIO message.
I have install as per the normal procedure the 99-platformio-udev.rules
If I do an lsusb command I can see the leaf
Thank you sooo much for your support.
Regards,
Rene-Jean
Hi Peter,
Continuing on the same episode, if I use the stlnk-v2 to program then the serial port gets to life.
Here are some screenshots.
Is it system (Debian) related of application related?
Regards,
Rene-Jean
Is /dev/ttyACM0 the correct serial port for it? What does
pio device list
say when the stm32 is connected?
Hi Peter,
First, to answer your question (before you ask : appropriate bootloader either the “regular” or “fast” version (tried both) from Roger Clark for the STM-32 were installed). “pio device list” command gives an empty message:
Knowledge that I am member of the groups dialout and plugdev :
Tried all the combination of ownership and group for directories : /etc/udev, /etc/udev/rules.d. No result.
Tried to modify the 99-platformio-udev.rules for the “leaf” portion (see below). No result.
Tried to create a node (mknod /dev/ttyACM0 188 0) and (mknod /dev/ttyUSB0 188 0). Port shows up but not available.
Decided to plug back the stlink-v2 and progam the STM32_BluePill. Works well.
After the programming above tried to open the port AFTER HAVING CONNECTED THE USB CABLE to the STM32. Here is the message to the “pio device list” command:
And opening the serial monitor I get this ok message :
I am out of luck and ideas of things to try.
Recall of the system installed :
Your help will be much appreciated.
Thank you so much Peter!
Regards,
Rene-Jean
Ok, just so I’m clear on this… using the STLink, you can both program the STM32, and access it’s serial console via the STLink? But if you try to directly connect the STM32 via USB, even though it has a DFU bootloader, it doesn’t let you program it, or appear as a serial port?
Are you using one of these STM32F103C8s? Note there is a fault on them (mentioned further down that page) which needs a resistor to be changed before the USB works properly for some machines. I’ve got both them and the Maple Mini clones. I’ll try over the next day or two to see if I can get them up and running again on linux.
I just tried out two of the former F103C8s, and luckily enough it was one I’d programmed the DFU bootloader onto + a blinky sketch, so it did more than just enumerate as a device, but also loaded the serial port… without that, you won’t get the bottom 7 lines if you’re running dmesg -w while connecting the device, but only the earlier ones.
[ 4041.388336] usb 4-1.6.2: new full-speed USB device number 18 using ehci-pci
[ 4041.586678] usb 4-1.6.2: New USB device found, idVendor=1eaf, idProduct=0003, bcdDevice= 2.01
[ 4041.586684] usb 4-1.6.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 4041.586687] usb 4-1.6.2: Product: Maple 003
[ 4041.586690] usb 4-1.6.2: Manufacturer: LeafLabs
[ 4041.586692] usb 4-1.6.2: SerialNumber: LLM 003
[ 4043.900270] usb 4-1.6.2: USB disconnect, device number 18
[ 4044.204989] usb 4-1.6.2: new full-speed USB device number 19 using ehci-pci
[ 4044.404781] usb 4-1.6.2: New USB device found, idVendor=1eaf, idProduct=0004, bcdDevice= 2.00
[ 4044.404786] usb 4-1.6.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 4044.404789] usb 4-1.6.2: Product: Maple
[ 4044.404792] usb 4-1.6.2: Manufacturer: LeafLabs
[ 4044.405337] cdc_acm 4-1.6.2:1.0: ttyACM0: USB ACM device
I haven’t changed the R10 resistor on this one, as I seemed to be able to get away with not doing that yet, but when I tried to program it, I had to retry it several times, and reset the board between attempts as it just sat in a state with PC13 ‘throbbing’… but it did finally take…
Good morning Peter,
Using the STLink, I can program the STM32 Bluepill and get the messages of the execution of my program out of the Bluepill to the computer via the Bluepill USB port.
The DFU bootloader from Roger Clark for the Bluepill (exactly as given at the pointer of your message (Roger Clark procedure)) …be the regular (generic_boot20_pc13.bin) or the fast bootloader (generic_boot20_pc13_fastboot.bin) is what is programmed in the Bluepill.
Yes R10 resistor has been replaced by a 1.5k ohms and verified with an ohmeter on all the 6 Bluepill I regularly used to develop programs.
The uploading used to work fine when the core was at 3.x.x but I cannot confirm that the problem came at the transition from core 3 to core 4 because it coincides with my installation of the latest Debian 10.
When I click on the “serial monitor icon” I get :
When I tell PlatformIO to look for /dev/ttyACM0 I get :
When I use the command dmesg -w …and I press the reset button on the Bluepill I get (…there are variances with the message you get, but I am not qualified enough to see the subtleties) :
Peter, if you feel that I should try the core prior to version 4, let me know and give me a pointer to where I should look for it.
Thank you very much for your support.
Regards,
René-Jean
I think the underlying problem is something is not right in your Debian install… if you don’t get the second part of this output… it doesn’t matter what version of PIO you use… something is stopping the STM32s from enumerating as a serial device.
I don’t pretend in any way to fully understand the process, but I am in the belief that once a sketch is on the device (hence why we’re told to upload the blink sketch so that a sketch is loaded after the DFU bootloader is written), it will enumerate as a usb serial device, with a VID:PID of 1eaf:0004. When that is the case, when you program the device, it resets the 1eaf:0004 device, which triggers the bootloader, which enumerates as 1eaf:0003 for about 2 seconds, and then starts the user program, hence 1eaf:0004 appears. In other words, I have merely plugged in the usb lead, and first the DFU bootloader has been detected, and then the blink sketch that was programmed started up after about 2-3 seconds without touching the device. If I run the maple-reset command… it should cycle through those two states without me even touching it.
I probably won’t have time to look at this tomorrow, so it maybe Sunday before I can look into this further. It might be worth seeing if you’re suffering from the same problem I was with a Arduino Micro, which is that the ModemManager service was stopping it resetting properly. You can do a sudo systemctl stop ModemManager and that will simply stop the service. If the device properly enumerates, you’ve found your culprit. If you don’t use a USB modem, you can probably just disable that service using sudo systemctl disable ModemManager as stopping it will only last until you reboot.
Hi Peter,
Thank you for your quick reply.
I tried the systemctl disable ModemManager but not much luck.
What I did was to I fully erase the STM32 and put a fresh bootloader on the STM32 to make sure nothing was corrupted. Same message:
Then I ran the dmesg -w command . Same as reported before:
Then I connected the STLink and programmed my application. …No problem.
Then I ran again dmesg -w command with the STM32 USB port cable connected. …And the cdc acm line appeared. …But there is no underscore between the cdc and the acm (makes a difference?).
Then I Clicked on the Pio Serial Monitor icon. …Then I saw that the port was there !
But since the boot-loader has been erase (totally?/partially?) by the STLink, PlatformIO in DFU mode cannot load the program.
I am glad to see that you don’t give up. Thank you soooo much.
Looking forward to getting news from you on Sunday or the days after.
Regards,
Rene-Jean
Well, I haven’t given up… but I’m not getting any further…
I have two of the stm32s which I’ve done the 1.8K to 3v3 mod instead, and whilst they appear to be consistently uploading on Windows - both the Arch linux host and Debian Buster VM are 1 in 4 successful uploads (if that), and often that’s with a manual reset via the button… I’m also getting “resource busy” and all other sorts of weird errors when just trying to view the serial output via the Arduino IDE, so that’s not good either. I’ll keep working on it…
PS: So, after setting up a live Debian Buster USB install, I was at least able to confirm it’s not a fault on my end with the VM… I’m getting the same results on the actual hardware… bootloader and ‘serial’ are starting… but it either doesn’t reboot the STM32 properly (goes into that ‘throbbing’ mode rather than fast blink -> slow blink -> program start ) and even if I do a manual reset the DFU loader doesn’t seem to recognize the STM32… user is the right groups, platformio udev rules applied, permissions seem fine… it just don’t wanna work! 
Hi Peter,
Thank you very much for your patience and all the efforts you are putting on the problem we are experiencing on Linux/PIO.
I thought I was doing something wrong or missing something.
Are you going to call further for help ? I am thinking about Ivan Kravets. May be he is already aware of the problem. It might be an incompatibility between PIO and the latest release of Debian?
Anyway. Looking forward to more development from your part.
Regards,
Rene-Jean
I’ll probably have to go further afield and see if anyone over at the stm32 arduino forums or on rogerclarkmelbourne/Arduino_STM32 knows about it, as it is more than just PlatformIO. The Arduino core PlatformIO is using is suffering the same issues… although from one of the comments I was just reading… it sounds like DFU and blue-pills is a nightmare… recommendation is to use the maple hardware for testing, and then upload final stuff to a blue pill… just to avoid the whole saga… and there are no end of ‘DFU not working’ posts on the STM32 forums… usually caused by permissions, udev rules, bad cables… quite annoying, really… they fixed their problems!
btw, if you want to test something stupid… Upload this with your STLink, and you should get output on /dev/ttyACM0 if it is working at all…
#include <Arduino.h>
void setup()
{
pinMode(LED_BUILTIN, OUTPUT);
digitalWrite(LED_BUILTIN,LOW);
Serial.begin(115200);
}
void loop()
{
digitalWrite(LED_BUILTIN, !digitalRead(LED_BUILTIN));
Serial.print("LED = ");
Serial.println(digitalRead(LED_BUILTIN));
delay(500);
}
Hi Peter,
Thank you for your support.
For the moment, and until the problem is resolved, I am using a STLink-v2 to program the BluePill and my BluePill USB port is connected to a hub, to my computer, and I get the communication/messages correctly displayed.
Regards,
Rene-Jean
So far, this topic is the closest to the problem I’m facing.
Since this is an old topic, I was hopping to find a solution. I’m assuming that I am doing something wrong.
My goal:
I’m using bluepill to process something when it receives a serial (usb /dev/ttyACM0) command. Basically send 433MHz signals.
The problem:
Lot of recommendations states to not power usb and st-link at the same time. Since serial communication demands debug, I decided to go with dfu bootloader 2.0.
Using arduino IDE is no big deal. I use dfu mode, upload using usb and communicate with usb.
I can’t get that working with plataformio. I’ve cycling between readings and readings.
Is this not fixed yet?
[env:bluepill_f103c8]
platform = ststm32
board = bluepill_f103c8
framework = arduino
upload_protocol = dfu