Blue Pill USB issue connected to Raspberry Pi

I recently purchased a few Blue Pill boards from Ali Express and have read as many threads as I could find on installing the bootloader and setting up Arduino IDE. So far I’ve been relatively successful getting things setup on a Windows environment and have been able to program the board. I changed the 10K resistor to 1.5K however I still need to hit the reset button before the upload starts to get it to work. I’d like to get it to work without hitting reset but this isn’t a big deal.

The main problem that I’m trying to resolve is when connecting it to a Raspberry Pi 3 B+. I have an application that I built on a Pro Micro that is connected to the Raspberry Pi via USB. I have the Arduino IDE setup on the Rpi so I’m able to program the Pro Micro directly as well as monitor the serial port and send data to the Pro Micro using Cute Com. I’m hoping to do the same thing with the Blue Pill, however I’m having issues with the USB. When I connect the Blue Pill I see the connection in dmesg and in lsusb but it’s not assigning a new device. I connected the Blue Pill to my Ubuntu 16.04 laptop and it created ttyACM0 and I was able connect to the board via Cutecom without problems.

Has anyone had success getting a working USB connection between a Raspberry Pi 3 B+ (Raspbain Stretch) and a STM32F103 generic board?

Have you installed the usb drivers onto RasPi?

Is there a special USB driver I need specifically for the Blue Pill? I have no issues connecting via USB from the same RPi to the Pro Micro and ESP8266 boards.

[stevestrong – Wed Oct 31, 2018 3:16 pm] –
http://wiki.stm32duino.com/index.php?title=Installation

That is the process I went through. I don’t see anything specific for the RPi. I went through the same process on my Ubuntu box and it worked fine so I’m not understanding what is different in the process or drivers for the RPi

Here is the USB dmesg output on the RPi
pi@raspberrypi:~/Arduino/hardware/Arduino_STM32/tools/linux $ dmesg | grep usb
[133449.833433] usb 1-1.2: new full-speed USB device number 6 using dwc_otg
[133449.966089] usb 1-1.2: New USB device found, idVendor=1eaf, idProduct=0003
[133449.966106] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[133449.966115] usb 1-1.2: Product: Maple 003
[133449.966124] usb 1-1.2: Manufacturer: LeafLabs
[133449.966132] usb 1-1.2: SerialNumber: LLM 003


Sorry, but I am not an expert for RasPi.
Do you have a USB hub on Pi? Try without.

[stevestrong – Wed Oct 31, 2018 4:39 pm] –
Sorry, but I am not an expert for RasPi.
Do you have a USB hub on Pi? Try without.

No USB hub,, I appreciate your help. Thanks.

I’ve tried my bluepill on a Raspberry Pi 2 with the Raspbian 9.4 with all apt-get updates and it worked fine using either the pi USB port or on a powered hub.

I did create the 45-maple.rules file in /etc/udev/rules.d/ as the linux instructions indicate. I then rebooted the pi and it showed up as /dev/ttyACM0. I used putty to see the output.

ATTRS{idVendor}=="1eaf", ATTRS{idProduct}=="0004", ENV{ID_MM_DEVICE_IGNORE}="1"
ATTRS{idVendor}=="1eaf", ATTRS{idProduct}=="0004", ENV{MTP_NO_PROBE}="1"
SUBSYSTEMS=="usb", ATTRS{idVendor}=="1eaf", ATTRS{idProduct}=="0004", MODE:="0664"
KERNEL=="ttyACM*", ATTRS{idVendor}=="1eaf", ATTRS{idProduct}=="0004", MODE:="0664"


Hi Rick,

Does your RPi create a ttyACM0 when the blue pill is plugged in? I went through the install again and double checked the 45-maple.rules file and still doesn’t work. When I run lsusb it’s showing the device id as 0003 rather than 0004 but I tried both in the rules file and neither one works.

John

Yes, it shows up when I plug it in. It also re-enumerates if I press the reset button.

I don’t have a bootloader on my bluepill so it would never show up as 0003. Are you loading a sketch that is using the Serial port? Try the ASCIITable example.

Not sure what I’m overlooking. I tried it on another RPi from scratch and same issue… no ttyACM0

I plugged a Pro Micro into the same RPi and it creates the ttyACM0. The dmesg output is below. Then you can see what happened when I unplugged the Pro Micro and plugged in the blue pill. The output is same up until the ‘cdc_acm 1-1.1.2:1.0: ttyACM0: USB ACM device’ when the ttyACM0 is created.

[512574.356748] usb 1-1.1.2: new full-speed USB device number 27 using dwc_otg
[512574.505230] usb 1-1.1.2: New USB device found, idVendor=2341, idProduct=8036
[512574.505247] usb 1-1.1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[512574.505256] usb 1-1.1.2: Product: Arduino Leonardo
[512574.505265] usb 1-1.1.2: Manufacturer: Arduino LLC
[512574.506595] cdc_acm 1-1.1.2:1.0: ttyACM0: USB ACM device
[512714.860884] usb 1-1.1.2: USB disconnect, device number 27
[512723.607817] usb 1-1.1.2: new full-speed USB device number 28 using dwc_otg
[512723.740478] usb 1-1.1.2: New USB device found, idVendor=1eaf, idProduct=0003
[512723.740494] usb 1-1.1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[512723.740504] usb 1-1.1.2: Product: Maple 003
[512723.740512] usb 1-1.1.2: Manufacturer: LeafLabs
[512723.740521] usb 1-1.1.2: SerialNumber: LLM 003


Why don’t you try getting rid of the bootloader:

[512723.740478] usb 1-1.1.2: New USB device found, idVendor=1eaf, idProduct=0003

That indicates the device is enumerating as a DFU device. You aren’t going to see a tty while that is running.

There is a known issue with the Rpi 3B + (note this applies only to the ‘ plus ‘ version)

It does not accept the hack to re-enumerate the bus.

I did investigate this for the Amateur radio community who use the bootloader and also the same code to reset the bus, in their own code, and they did come up with a solution that ONLY works on the RPI 3B+ by changing the reset pulse length so it was much much longer (something like like 1mS long)

So they run a special copy of the bootloader and modified their firmware to use much longer reset pulses.

But I can’t put this into the general bootloader as long reset pulses are not compatible with PC’s or Macs etc

As both the bootloader and the core is open source, you’ll need to make your own modifications to the reset pulse length to make it work for you, but the resultant bootloader will only work on your RPi 3B+

[Rick Kimball – Wed Oct 31, 2018 10:18 pm] –
Why don’t you try getting rid of the bootloader:

[512723.740478] usb 1-1.1.2: New USB device found, idVendor=1eaf, idProduct=0003

That indicates the device is enumerating as a DFU device. You aren’t going to see a tty while that is running.

It works as is, with the bootloader, on my Ubuntu and Windows boxes. It’s just the RPi 3 B+ that has the problem. Sounds like it’s a known issue with the plus version. I’ll look into the delay and see if I can get it working. Thanks for all the help.

Yes.

Its a known issue on the 3B+ , the 3B was fine.

I’m not sure if RPi will fix this themselves, probably not, since the reset we use is a bit of a hack.

but it does work on 99% of other computers