0
\$\begingroup\$

This is as much a software question as it is electronics question, but here we go. I am very new to STM32 micro controllers and I've been sitting with this problem for the last 3 days of so

My goal: send a string using CDC_Transmit_FS(string,sizeof(string)); from a STM32F401RE (NUCLEO Dev board) to PC via Full Speed USB through Virtual Com Port.

Problem: PC does not recognize STM32 as a Full Speed USB device. Fails to enumerate it.

Here is output from sudo dmesg:

[87338.796874] debugfs: Directory '27' with parent 'devices' already present!
[87338.910843] usb 2-2: new low-speed USB device number 58 using xhci_hcd
[87339.025875] usb 2-2: device descriptor read/64, error -71
[87339.243812] usb 2-2: device descriptor read/64, error -71
[87339.352913] debugfs: Directory '28' with parent 'devices' already present!
[87339.466841] usb 2-2: new low-speed USB device number 59 using xhci_hcd
[87339.581882] usb 2-2: device descriptor read/64, error -71
[87339.803879] usb 2-2: device descriptor read/64, error -71
[87339.912941] usb usb2-port2: attempt power cycle
[87340.224912] debugfs: Directory '29' with parent 'devices' already present!
[87340.540844] usb 2-2: new low-speed USB device number 60 using xhci_hcd
[87340.541475] usb 2-2: Device not responding to setup address.
[87340.541598] debugfs: Directory '30' with parent 'devices' already present!
[87340.745309] usb 2-2: Device not responding to setup address.
[87340.745485] debugfs: Directory '22' with parent 'devices' already present!
[87340.952785] usb 2-2: device not accepting address 60, error -71
[87341.066838] usb 2-2: new low-speed USB device number 61 using xhci_hcd
[87341.067472] usb 2-2: Device not responding to setup address.
[87341.273463] usb 2-2: Device not responding to setup address.
[87341.273584] debugfs: Directory '02' with parent 'devices' already present!
[87341.480837] usb 2-2: device not accepting address 61, error -71
[87341.480949] usb usb2-port2: unable to enumerate USB device

Output from sudo lsusb and sudo lsusb -t:

[veta@equis ~]$ sudo lsusb
Password: 
Bus 003 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 004: ID 04f2:b2ea Chicony Electronics Co., Ltd Integrated Camera [ThinkPad]
Bus 001 Device 007: ID 0a5c:21e6 Broadcom Corp. BCM20702 Bluetooth 4.0 [ThinkPad]
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 002 Device 057: ID 0483:374b STMicroelectronics ST-LINK/V2.1
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
[veta@equis ~]$ sudo lsusb -t
/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 480M
    |__ Port 1: Dev 57, If 0, Class=Vendor Specific Class, Driver=, 12M
    |__ Port 1: Dev 57, If 1, Class=Mass Storage, Driver=usb-storage, 12M
    |__ Port 1: Dev 57, If 2, Class=Communications, Driver=cdc_acm, 12M
    |__ Port 1: Dev 57, If 3, Class=CDC Data, Driver=cdc_acm, 12M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M
        |__ Port 4: Dev 7, If 2, Class=Vendor Specific Class, Driver=btusb, 12M
        |__ Port 4: Dev 7, If 0, Class=Vendor Specific Class, Driver=btusb, 12M
        |__ Port 4: Dev 7, If 3, Class=Application Specific Interface, Driver=, 12M
        |__ Port 4: Dev 7, If 1, Class=Vendor Specific Class, Driver=btusb, 12M
        |__ Port 6: Dev 4, If 0, Class=Video, Driver=uvcvideo, 480M
        |__ Port 6: Dev 4, If 1, Class=Video, Driver=uvcvideo, 480M

Power is fed via the programmer ST-LINK, which is connected to same PC, different USB port.

I have split open a USB cable and soldered header pins to each of the 4 wires inside.

  • White (D+) is connected to PA12
  • Green (D-) is connected to PA11
  • Red (VBUS) is connected to PA9
  • Black (GND) is redundant as the MCU is fed from same power source, but I have tried with it connected to one of the GND pins too

I have also tried setting USB into FS mode manually by pulling up D+ USB pin with a 1.5k Ohm resistor: manual-Dp-pull-up

and leaving pulling-up to the MCU to handle: stm32-Dp-pull-up

In STM32CubeMX my configuration is as follows, everything else is left default:

USB_OTG_FS under Connectivity tab:

  • Mode: Device Only
  • Activate VBUS: yes
  • Avtivate SOF: no

USB_DEVICE under Middleware tab:

  • Class for FS IP: Communication Device Class (Virtual Port Com)

RCC under System Core tab:

  • High Speed Clock: Crystal/Ceramic Resonator

Clock Configuration is set in such a way, so that 48MHz clocks is set to 48MHz.

If something is unclear, tell me so. It's 2 am and I was working with this for last 15 hours now.

\$\endgroup\$
0
\$\begingroup\$

USB specs say green is D+ and white is D-, but in reality who knows which way they are connecte so better check it. Also just in case you are using a separate ST-Link pod instead of the one that is integrated on the Nucleo, a separate ST-Link device does not output 3.3V so it will not power external devices (it is used as a voltage reference for other wires) but a Nucleo board with embedded ST-Link the USB debug connector should power up the whole board.

\$\endgroup\$
2
\$\begingroup\$

87339.466841] usb 2-2: new low-speed USB device number 59 using xhci_hcd

This is a direct result of pulling up D- rather than D+. Even if you had no MCU, just getting that right would change the detection message.

Check your wiring.

Check all your assumptions - for example, it is not a safe assumption that on some random cable you cut up, white is D+ and green is D-. Or for that matter that red and black are what you think they are. There is also at least one website with a picture (quoted here in the past) that shows the D+ and D- lines in the wrong places on a USB connector.

Try connecting only ground and D+ to 3v3 via the resistor - if you are actually pulling up the correct line, you will get a message about detecting a full speed device. Of course without the MCU and appropriate firmware enumeration will still fail, but detection will be correct.

\$\endgroup\$
  • \$\begingroup\$ Thank you so much, you're a Godsend! That was it. So much headache and time could have been spared had I not made that assumption \$\endgroup\$ – Vitalijs Bernis Nov 15 at 7:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.