El estado del enlace USB se desconecta al salir del modo de suspensión profunda

Estoy desarrollando la función de hibernación USB en la plataforma que usa el controlador USB Synopsis DWC3. Cuando el USB solo se reanuda desde el estado de suspensión, no hay problema.

Pero estoy enfrentando un problema mientras mi dispositivo se reanuda desde el modo de suspensión profunda. Mientras se reanuda, el estado de enlace aparece como 4 (desconectado), lo que conduce a la reenumeración de USB.

Del equipo de hardware hay una consulta sobre este problema que no puedo entender. Por favor ver más abajo,

En el sueño profundo observamos:

  1. una amplitud de señal de pico de microtrama mucho mayor de lo esperado (casi el doble);
  2. un desplazamiento de nivel cero no deseado antes del micro-trama.

Estos malos comportamientos coinciden con la hipótesis de que falta una terminación 0 de un solo extremo (SE0) en uno de los extremos que dan a la secuencia. Dado que el host es el maestro de Suspensión/Reanudación que funciona correctamente con cualquier otro dispositivo USB 2.0, debemos suponer que el extremo del dispositivo pierde su conexión de terminación de alta velocidad (HS) de 45 ohmios (es decir) al final de la fase de Reanudación.

Por especificación, el dispositivo debe conectar la terminación HS dentro de los 1,33 us desde el final de la reanudación (USB D-flang down), por lo que esto normalmente lo hace el hardware USB 2.0 PHY listo para reaccionar con anticipación desde que comenzó el estado de reanudación. Observamos que el dispositivo detecta el inicio del estado de reanudación correctamente, al aumentar el consumo de energía en unos pocos milisegundos, lo que indica una reacción rápida para salir del estado de suspensión profunda. La reanudación durará no menos de 20 ms, lo que es suficiente para preparar USB 2.0 PHY para estar listo para responder a la detección de finalización de reanudación y la terminación SE0 relevante requerida por el enlace de comunicación HS.

Si el dispositivo SE0 falla, el aumento de la amplitud de la señal monitoreada por el host que se produce en el primer microfotograma hace que el host entre en un estado de desconexión de alta velocidad, seguido de un restablecimiento de USB, negociación de FS a HS, reenumeración, etc.

¿Alguien podría explicar cuál es la consulta anterior?

Veo que se le recomendó hacer la pregunta aquí, cuando publicó la misma pregunta en Stack Overflow . En ese caso, debe eliminar la pregunta en Stack Overflow, ya que generalmente se desaconseja tener preguntas duplicadas en diferentes partes de Stack Exchange/Stack Overflow, ya que puede duplicar el esfuerzo y desperdiciar el tiempo de las personas.
¿Qué quiere decir con "suspensión profunda" en comparación con "suspensión USB"? El marco USB no define un concepto de ningún sueño "profundo" o "ligero". Si quiere decir que su MCU no puede finalizar correctamente el estado de suspensión USB si está en "estado de suspensión profunda de MCU", entonces su problema está en la administración de energía de su MCU.

Respuestas (1)

debemos suponer que el extremo del dispositivo pierde su conexión de terminación de alta velocidad (HS) de 45 ohmios (es decir) al final de la fase de reanudación.

A partir de la descripción del "equipo de hardware", su dispositivo no pudo restaurar la terminación HS después del final de RESUME, lo que resulta en la desconexión HS (la amplitud del micro-trama se duplica debido a la ausencia de terminación en el diseño de su dispositivo).

Tenga en cuenta que falta una parte importante del protocolo RESUME en la descripción: en RESUME iniciado por el host (estado K), el dispositivo debe VOLVER al MISMO estado de línea (estado K) como señal de reconocimiento. El host reconoce este estado bidireccional cuando expira el tiempo de espera de 20 ms del lado del host, pero el bus permanece en el estado K. Luego, el host espera a que el dispositivo finalice el estado K y continúa con la reanudación del tráfico inactivo (SOF) de HS.

Por lo tanto, esta es la responsabilidad del dispositivo para finalizar la condición de REANUDAR y afirmar la finalización del HS de manera oportuna (1.33us). Parece que falta todo el formulario de respuesta del protocolo de su dispositivo. Su dispositivo recibe el RESUME correctamente, pero no responde correctamente. Faltan algunos enlaces (quizás a la parte de administración de energía del software del dispositivo).

Gracias por su respuesta. Tendré una discusión interna sobre su respuesta.
Al comparar los registros, veo que en el escenario de éxito la velocidad de conexión se detecta como HS, mientras que en caso de falla, la detección de velocidad es FS. ¿Tiene algo que ver con la consulta anterior? En caso afirmativo, ¿qué módulo es responsable de la detección de velocidad HS/FS?
@ user3267021, comparar registros después de la falla no dice mucho. El proceso es dinámico, todo a nivel de hardware. Necesita adquirir trazas de alcance largas (300-400 ms) de D+ y D-, con una resolución profunda de submicrosegundos para garantizar la salida correcta de REANUDAR. Repito, el proceso de salida del estado SUSPEND se describe/comprende incorrectamente en la "consulta": falta la finalización adecuada del protocolo RESUME. Pero si desea una breve explicación sobre cómo funciona la detección de FS/HS, consulte superuser.com/a/1130446/620011