Dispositivo USB STM32: la solicitud del descriptor del dispositivo falló

Estoy usando STM32F7-45 en mi propia placa y estoy tratando de programar un dispositivo USB (probé COM virtual y HID, por separado).

Pero después de conectarlo a la PC, se detecta (después de un tiempo) con el error " Dispositivo desconocido (falló la solicitud del descriptor del dispositivo) ".

Eléctricamente (PCB):
creo que la PCB no es un error aquí; solo tengo pistas cortas D+ y D- desde el conector hasta el uC y eso es todo.
Tengo un pull-up 1.5k (lo probé con y sin él), pero ni siquiera es necesario en STM32. He comprobado la conexión y un cable y estoy seguro de que se conecta.

Código:
estoy usando código generado por HAL y STM32CubeMx fusionado con mi proyecto. Generalmente los programas se congelan.

1) Después de ejecutar la línea (del código de la biblioteca) USBx->GAHBCFG |= USB_OTG_GAHBCFG_GINT;. Lo sé, ya que intenté imprimir antes y después de esa línea y solo se imprime primero printf(). No entiendo cómo el programa puede atascarse allí.
De todos modos, si desactivo la detección de VBUS, el programa no se atasca allí y todo MX_USB_DEVICE_Inittermina.

2) Pero luego, el programa ejecuta algunos ciclos (por ejemplo, imprimirá "hecho" y encenderá el LED) y luego se congela. Completamente. Este LED debería parpadear en un bucle infinito, pero no lo hace. Tengo otro LED para habilitar en todos los controladores de errores (como fallas graves, etc.) y parece que el programa no va allí (ya que el LED está apagado), así que no entiendo dónde se atasca.

  • Después de COM virtual, probé HID pero fue en vano. Me da el mismo comportamiento.
  • Si enciendo la placa desde el cargador (no desde la PC), el programa no se atasca.
Hola MasMas :). ¿Tienes un depurador? ¿Qué significa freezes? ¿Qué significa ' But then, program executes few cycles'? ¿Ciclos de qué? ' it will print "done" and lit the LED' - a través de USB recién inicializado?. En realidad, su descripción está lejos de ser técnica o comprensible.
Puede que no sea la mejor descripción, ya que quería ser breve. ¿Se congela? Bueno, pensé que no era ambiguo: no hace las siguientes instrucciones en el código, simplemente deja de ejecutarlas, probablemente salta a alguna interrupción (o no sé) o tiene algún otro error. ¿Unos ciclos de qué? Por supuesto de CPU = pocas instrucciones. Imprimirá "hecho" en la terminal a través de UART. Tengo ST-Link.
I have ST-Link- así que mira dónde terminas. Tener el depurador y la escritura probably jumps somewheremuestra que su esfuerzo de depuración estuvo lejos de ser suficiente.
Bueno, nunca he usado ST-Link para otra cosa que no sea programar el flash, por eso... Por lo general, estaba bien con UART. Estoy usando Visual Studio y VirtualGDB pero no pude hacer que mi st-link funcione con eso. Primero tengo que aprenderlo, luego lo intentaré y volveré aquí.
¿Así que vio "Dispositivo USB desconocido (falló la solicitud del descriptor del dispositivo)" pero los primeros ciclos del código funcionaron de todos modos?

Respuestas (2)

He resuelto el problema. No sé cuál fue el problema, pero hice otro proyecto y ahora todo funciona perfectamente.

Para hacer que esta publicación sea un poco más valiosa para otros que puedan encontrarla: al principio usé un programa generado a través de STM32CubeMx, y tiene los problemas descritos aquí. Me sugirieron descargar STM32F7Cube (Cube no CubeMX) y usar los ejemplos de allí. Hice eso y todo está funcionando.

Básicamente, todo esto significa que tiene un dispositivo USB muerto. Su dispositivo STM32 tiene un pull-up D+, por lo que una PC reconoce la conexión. Sin embargo, cuando el host intenta obtener el descriptor del dispositivo, es probable que su dispositivo no responda en absoluto porque no tiene un código que se ejecute correctamente dentro de su STM32. Generalmente, el programa debe ejecutarse y no debe congelarse. Si deshabilita la detección de VBUS (que es la señal principal para STM de que un host USB está conectado), es probable que su programa no haga nada, es por eso que al menos finaliza la inicialización. Por lo tanto, debe depurar su código STM y comprender por qué se congela.

También es posible que la conexión de su hardware sea incorrecta. Sugeriría encarecidamente obtener un diseño de referencia STM y conectar su hardware exactamente como en la placa de referencia.

Gracias, agradezco la respuesta, pero honestamente no es muy útil :) Quiero decir, me escribiste que mi programa no funciona y que debería depurarlo, eso es lo que sé, pregunté qué podría salir mal, porque estoy Me quedé sin ideas, lo estuve depurando todo el domingo... Tengo el hardware hecho como en la placa de descubrimiento STM, además solo dos líneas que conectan el conector y el uC; es difícil cometer el error allí. Y he comprobado las conexiones físicas.
@zupazt3, entiendo. Pero dos cables entre el conector USB y el IC no son suficientes. Debe proporcionar una conexión VBUS con una traducción de nivel adecuada como entrada (no necesaria como alimentación) para iniciar la ejecución de su código. O deshabilite correctamente esta función de detección en el caso de un dispositivo alimentado por bus. Un enlace a los esquemas de su tablero de descubrimiento sería útil para comprender su situación.
Sí, he enrutado Vcc desde USB a la línea VBUS en STM32. No creo que necesites ningún nivel de traducción. La línea VBUS es tolerante a 5V y también ST no usa ninguna traducción en sus tableros de descubrimiento. Además, probé el código con la detección VBUS habilitada y deshabilitada (como se describe en la primera publicación). Enlace al tablero de descubrimiento st.com/content/ccc/resource/technical/document/user_manual/f0/…
@zupazt3, ¿podrías ser un poco más específico? ¿Qué interfaz estás usando? ¿Puerto ULPI PHY o OTG FS? ¿Qué haces con el pin de identificación? Si deriva su diseño del kit de referencia, el ejemplo de código proporcionado debería funcionar. Comience con el código del kit de referencia y luego modifíquelo gradualmente según sus necesidades.
Dispositivo USB STM32: la solicitud del descriptor del dispositivo falló
RespuestasAquíPolítica de privacidad1y, 1v