1
\$\begingroup\$

I'm using STM32F7-45 on my own board, and I am trying to program USB device (I tried virtual COM and HID, separately).

But after plugging into PC it is detected (after a while) with "Unknown device (device descriptor request failed)" error.

Electrically (PCB):
I think that PCB is not an error here - I just have D+ and D- short tracks from the connector to the uC and that's all.
I have a pull-up 1.5k (I tried with and without it), but it is not even needed in STM32. I have check connection and a cable and I'm certain it connects.

Code:
I'm using HAL and STM32CubeMx generated code merged with my project. Generally programs freezes.

1) After executing line (from library code) USBx->GAHBCFG |= USB_OTG_GAHBCFG_GINT;. I know that, as I tried printing before and after that line and only first printf() prints. I don't understand how the program can stuck there.
Anyway, if I disable VBUS sensing then the program doesn't get stuck there and the whole MX_USB_DEVICE_Init finishes.

2) But then, program executes few cycles (for example, it will print "done" and lit the LED) and after that it freezes. Completely. This LED should blink in an infinite loop, but it doesn't. I have other LED to be enabled in all error handlers (like hard fault etc.) and it seems that the the program doesn't go there (as the LED is off), so I don't understand where it get stuck.

  • After virtual COM, I tried HID but to no avail. It gives me the same behavior.
  • If I power the board from the charger (not PC) then the program doesn't get stuck.
\$\endgroup\$
  • 1
    \$\begingroup\$ Hi MasMas :). Do you have a debugger? What does it mean freezes? What does it mean 'But then, program executes few cycles'? Cycles of what? 'it will print "done" and lit the LED' - via just initialised USB?. Actually your description is far from being technical or understandable. \$\endgroup\$ – P__J__ Oct 30 '17 at 19:10
  • \$\begingroup\$ It may be not the best description as I wanted to keep it short.. Freezes? Well, I thought it's unambiguous - it doesn't do next instructions in the code, just stops executing them, probably jumps into some interrupt (or I don't know) or have some other error. Few cycles of what? Of course of CPU = few instructions. It will print "done" on terminal through UART. I have ST-Link. \$\endgroup\$ – zupazt3 Oct 31 '17 at 10:15
  • 1
    \$\begingroup\$ I have ST-Link - so check where you end up. Having the debugger and writing probably jumps somewhere shows that your debugging effort was far from being sufficient. \$\endgroup\$ – P__J__ Oct 31 '17 at 10:18
  • \$\begingroup\$ Well, I just have never used ST-Link for anything other than programming the flash, that's why... Usually I was fine with UART. I'm using Visual Studio and VirtualGDB but I couldn't make my st-link work with that. I first have to learn it, then I will try it and get back here. \$\endgroup\$ – zupazt3 Oct 31 '17 at 16:30
1
\$\begingroup\$

I've solved the issue. I don't know what the problem was, but I did another project and now everything is working perfectly.

To make this post a bit more valuable to others that may find it: At beginning I used a program generated via STM32CubeMx - and it has the problems described here. I was suggested to download STM32F7Cube (Cube not CubeMX) and use the examples from there. I did that and everything is working.

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

Basically all this means that you have a dead USB device. Your STM32 device has a D+ pull-up, so a PC does recognize the connection. However, when the host tries to get device descriptor, your device likely doesn't respond at all because you don't have correctly running code inside your STM32. Generally the program should run and shouldn't freeze. If you disable VBUS sensing (which is the major signal to STM that a USB host is connected), your program likely does nothing, that's why it at least finishes initialization. So you need to debug your STM code and understand why it freezes.

It is also possible that your hardware hook-up is wrong. It would strongly suggest to get a STM reference design and wire your hardware exactly as on the reference board.

\$\endgroup\$
  • \$\begingroup\$ Thanks, I appreciate the answer, but honestly it's not very helpful :) I mean, you wrote me that my program doesn't work and I should debug it - that's what I know, I asked what could go wrong - because I'm running out of ideas, I was debugging it the whole Sunday... I have hardware done as in STM discovery board, beside it just two lines connecting connector and the uC - it's hard to do the mistake there. And I've checked the physical connections. \$\endgroup\$ – zupazt3 Oct 30 '17 at 12:27
  • \$\begingroup\$ @zupazt3, I understand. But two wires between USB connector and IC is not enough. You must provide VBUS connection with proper level translation as input (not necessary as power), to start your code running. Or properly disable this sense feature in case of bus-powered device. A link to your discovery board schematics would be helpful to understand your situation. \$\endgroup\$ – Ale..chenski Oct 30 '17 at 18:45
  • \$\begingroup\$ Yes, I have routed Vcc from USB to VBUS line in STM32. I don't think you need any level translation. VBUS line is 5V tolerant and also ST doesn't use any translation on their discovery boards. Besides I tried code with both enabled and disabled VBUS sensing (as described in the first post). Link to the discovery board st.com/content/ccc/resource/technical/document/user_manual/f0/… \$\endgroup\$ – zupazt3 Oct 31 '17 at 10:18
  • \$\begingroup\$ @zupazt3, could you be a bit more specific? Which interface you are using? ULPI PHY or OTG FS port? What do you do with ID pin? If you derive your design from the reference kit, the supplied code example should work. Start with the code for the reference kit, and then modify it gradually for your needs. \$\endgroup\$ – Ale..chenski Oct 31 '17 at 16:37

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.