Device not enumerated in OSX

[jamiejones85]

I've flashed hid_generic_pc13.bin with stm32cube programmer When plugging in the USB with a known good cable the LED blinks quickly, I have 4 bluepills, all exhibit the same behaviour. I don't have a Windows machine to plug in to for comparison.

lsusb doesn't show anything up. lsusb Bus 020 Device 004: ID 05ac:0274 Apple, Inc.

dmesg 021759.199986 HS05@14200000: AppleUSBHostPort::disconnect: persistent enumeration failures Wireshark XHC20 capture wireshark.pcapng.gz

hid_generic_pc13.bin.zip

I've tried the Rodger Clarke Melbourne bootloader with built in sketch and that enumerated OK and I had the serial output but wasn't able to then use it to add my own sketched from the Ardunio IDE "Congratulations, you have installed the STM32duino bootloader See https://github.com/rogerclarkmelbourne/STM32duino-bootloader"

` 18.7.0 Darwin Kernel Version 18.7.0: Mon Apr 27 20:09:39 PDT 2020; root:xnu-4903.278.35~1/RELEASE_X86_64 x86_64

`

[KenjutsuGH]

What worked for me on a MacBook Pro Late 2011 with High Sierra, was to first connect a USB hub to the Mac, and then the BP via the hub. Why this works, I have no idea, but it is worth giving it a shot :-)

[jamiejones85]

Thanks KenjutsuGH, was worth a shot but no cigar. I'll stick with FDTI I think.

260843.619044 AppleUSB20HubPort@14210000: AppleUSBHostPort::disconnect: persistent enumeration failures

[wilkgr76]

On Windows 10, something similar happens: This is the same regardless of whether I connect to a USB 3 or 2 port. It also fails with my USB hub.

If you're using a blue pill, check the resistance between PA12 and 3v3, while the board is unplugged. It should be 1.5k but some boards have the incorrect value of 10k or 4.7k. This is the case with my board. My old PC didn't care but the new one does. This is incorrect - I previously had the Maple Bootloader 2.0 on this and the PC did recognise it.

[carlfarrington]

I seem to be having the same issue with a batch of WeAct v1.0 F103 "blue pill plus" boards. Legit WeAct Studio boards. I believe their bootloader is based on this project. They boot up and present a FAT volume. You're supposed to hold BOOT0 while resetting to get into DFU mode, but all I get is an unreconised USB device.

[pat1]

in Linux I get:

nov 12 15:01:48 linux.fritz.box kernel: usb 1-1.1.1: new full-speed USB device number 124 using xhci_hcd
nov 12 15:01:48 linux.fritz.box kernel: usb 1-1.1.1: device descriptor read/64, error -32
nov 12 15:01:48 linux.fritz.box kernel: usb 1-1.1.1: device descriptor read/64, error -32
nov 12 15:01:48 linux.fritz.box kernel: usb 1-1.1.1: new full-speed USB device number 125 using xhci_hcd
nov 12 15:01:48 linux.fritz.box kernel: usb 1-1.1.1: device descriptor read/64, error -32
nov 12 15:01:48 linux.fritz.box kernel: usb 1-1.1.1: device descriptor read/64, error -32
nov 12 15:01:48 linux.fritz.box kernel: usb 1-1.1-port1: attempt power cycle
nov 12 15:01:49 linux.fritz.box kernel: usb 1-1.1.1: new full-speed USB device number 126 using xhci_hcd
nov 12 15:01:49 linux.fritz.box kernel: usb 1-1.1.1: Device not responding to setup address.
nov 12 15:01:49 linux.fritz.box kernel: usb 1-1.1.1: Device not responding to setup address.
nov 12 15:01:49 linux.fritz.box kernel: usb 1-1.1.1: device not accepting address 126, error -71
nov 12 15:01:50 linux.fritz.box kernel: usb 1-1.1.1: new full-speed USB device number 127 using xhci_hcd
nov 12 15:01:50 linux.fritz.box kernel: usb 1-1.1.1: Device not responding to setup address.
nov 12 15:01:50 linux.fritz.box kernel: usb 1-1.1.1: Device not responding to setup address.
nov 12 15:01:50 linux.fritz.box kernel: usb 1-1.1.1: device not accepting address 127, error -71
nov 12 15:01:50 linux.fritz.box kernel: usb 1-1.1-port1: unable to enumerate USB device