0
\$\begingroup\$

I am trying to setup USB communication with an STM32F446RE

It is a custom board where:

  • The clock source is an external 8Mhz quartz
  • There is a micro USB port with USB+ connected to PA12 and USB- connected to PA11

The external quartz is working (I can load a firmware that just blinks a led) but I fail to enumerate the USB device with below message in the computer syslog.

I am using mbed with the NUCLEO F446RE configuration, I just enabled USB in the target configuration (USE_USB_OTG_FS type)

Also, I noted that if I plug the board even without a firmware that is supposed to use USB, my computer tries to enumerate the device, however it shows a different message (like it's trying to enumerate a low-speed device instead of high-speed)

Do you have any idea/clue what could be going wrong?

Oct 23 19:13:51 destiny kernel: [4213209.733361] usb 1-10: new full-speed USB device number 17 using xhci_hcd
Oct 23 19:13:51 destiny kernel: [4213209.861500] usb 1-10: device descriptor read/64, error -71
Oct 23 19:13:51 destiny kernel: [4213210.097415] usb 1-10: device descriptor read/64, error -71
Oct 23 19:13:51 destiny kernel: [4213210.333311] usb 1-10: new full-speed USB device number 18 using xhci_hcd
Oct 23 19:13:51 destiny kernel: [4213210.461545] usb 1-10: device descriptor read/64, error -71
Oct 23 19:13:52 destiny kernel: [4213210.697528] usb 1-10: device descriptor read/64, error -71
Oct 23 19:13:52 destiny kernel: [4213210.805438] usb usb1-port10: attempt power cycle
Oct 23 19:13:52 destiny kernel: [4213211.461355] usb 1-10: new full-speed USB device number 19 using xhci_hcd
Oct 23 19:13:52 destiny kernel: [4213211.461721] usb 1-10: Device not responding to setup address.
Oct 23 19:13:53 destiny kernel: [4213211.669583] usb 1-10: Device not responding to setup address.
Oct 23 19:13:53 destiny kernel: [4213211.877357] usb 1-10: device not accepting address 19, error -71
Oct 23 19:13:53 destiny kernel: [4213212.005324] usb 1-10: new full-speed USB device number 20 using xhci_hcd
Oct 23 19:13:53 destiny kernel: [4213212.005568] usb 1-10: Device not responding to setup address.
Oct 23 19:13:53 destiny kernel: [4213212.213745] usb 1-10: Device not responding to setup address.
Oct 23 19:13:53 destiny kernel: [4213212.421346] usb 1-10: device not accepting address 20, error -71
Oct 23 19:13:53 destiny kernel: [4213212.421442] usb usb1-port10: unable to enumerate USB device

```
\$\endgroup\$
6
  • \$\begingroup\$ You should validate your firmware on an actual nucleo, it's unclear if what you are right now is at all suitable. Attempted enumeration of a low-speed device comes from a pull-up on D- alone - irrespective of any firmware that might or might not support USB. An accidental mixup of D+ vs D- will cause a failed attempt to enumerate a full speed device as low speed... \$\endgroup\$
    – Chris Stratton
    Oct 23, 2020 at 18:26
  • \$\begingroup\$ Just having blink code work does not verify your crystal oscillator, as the chip always starts up from the internal oscillator which is perfectly sufficient for a blink attempt. You need to actually start the external oscillator, start a PLL based on it, lock that, and then switch to using the PLL as a clock source... \$\endgroup\$
    – Chris Stratton
    Oct 23, 2020 at 18:27
  • \$\begingroup\$ Yes I will try to get it working on an actual Nucleo first to be sure about the firmware \$\endgroup\$
    – Gregwar
    Oct 23, 2020 at 19:18
  • \$\begingroup\$ About the LED, I tested disabling HSI (if I unsolder the xtal it doesnt blink else it does). And thank you guys Im having a bad day :'-) \$\endgroup\$
    – Gregwar
    Oct 23, 2020 at 19:18
  • \$\begingroup\$ The code is working on Nucleo F446RE, which features the same micro controller I don't understand at all what is the difference now, and it still fails to enumerate my custom board \$\endgroup\$
    – Gregwar
    Oct 23, 2020 at 20:54

2 Answers 2

Reset to default
1
\$\begingroup\$

Yeah, well, your firmware needs to respond to the USB packets coming from the host. You seem to have enabled the USB hardware peripheral, but not included or at least not started any USB handling code.

\$\endgroup\$
1
\$\begingroup\$

Attempted enumeration of a low-speed device comes from a pull-up on D- alone - irrespective of any firmware that might or might not support USB. A pull-up on D+ would indicate a full-speed device (or a high speed one that must initially present as full speed before being stepped up)

In your case, what this low speed enumeration attempt was really reflecting was the accidental short between D- and VBus (which is additionally outside the bounds of the electrical spec, but probably survivable)

\$\endgroup\$

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.