¿Cuál es la fuente de esta forma en mi diagrama de ojo USB?

He diseñado un dispositivo USB en torno a un STM32F105 . Es un dispositivo USB 2.0 Full Speed ​​CDC configurado como un puerto COM virtual usando la biblioteca USB de ST . Utiliza el PHY integrado del STM32 y funciona a 12 Mbps.

Estoy enviando datos en paquetes de 254 bytes. De vez en cuando (con un promedio de 1 en 17000 paquetes) la computadora host recibe datos incorrectos. Generalmente está restringido a un solo byte en el paquete.

Así que estoy mirando las señales usando un O-scopio Tektronix TDS2025 (200 Mhz).


La mayoría de las transiciones se ven geniales:

USB1


Pero mi diagrama de ojo de baja tecnología muestra algo inesperado:

Ojo


Logré atrapar una de las malas formas de onda, que se ve así:

USB2


Que podria estar causando esto? No estoy seguro de por dónde empezar a buscar.

Cuando conecto el dispositivo por primera vez, la enumeración se lleva a cabo con éxito y el diagrama del ojo se ve limpio. Pero una vez que abro el puerto COM (usando PuTTY, Hercules o mi software Java personalizado), aparecen los problemas técnicos. Estoy usando un Lenovo Thinkpad con Windows 7.

Aquí hay una imagen del diseño:

tarjeta de circuito impreso

El TVS IC es un NXP PRTR5V0U2F y el cargador detector es un TI BQ24392 .

Los rastros USB viajan aproximadamente una pulgada en la parte posterior de la placa, luego regresan y se conectan directamente a los pines USB del microcontrolador. Están controlados por impedancia y tienen una longitud adecuada entre sí.

Estoy probando desde las almohadillas de soldadura del conector USB hasta el punto de tierra que he etiquetado en la imagen. La sonda tenía un resorte de tierra corto, no una pinza de cocodrilo larga.

Si más datos ayudarían, por favor hágamelo saber. Además, este es mi primer dispositivo USB y mi primera prueba de diagrama de ojo. Si ve algún problema con mi configuración o suposiciones, hágamelo saber.

2.2R como resistencia en serie para sus líneas de datos me parece bastante bajo. ¿Puede confirmar que es 2.2R y no 22R como esperaría? ¿Tienes un diseño de referencia de donde tomaste esto? Además, ¿puede confirmar que al menos intentó enrutar las líneas de señal USB con la misma longitud y aproximadamente 50 ohmios?
Es poco probable que el TVS o el detector de carga estén interfiriendo con la señal de esa manera. Sin embargo, no tengo idea de por qué el STM32 exhibiría ese comportamiento.
Eso parece un reflejo, pero tendría que estar en un cable bastante largo. ¿Quizás algún tipo de disputa? Creo que mi primera acción de depuración sería desoldar el detector del cargador y conectarlo con un par de cables.
Yo buscaría el problema en otro lado. Esta señal parece una transición de conducción (1 o 0) a Z alta.
@TomL., sí, son 2.2R. Provino de una placa de desarrollo en funcionamiento proporcionada por un fabricante de transceptores de RF que usa el mismo microcontrolador, pero en realidad nunca califiqué la señalización de la placa de desarrollo... Parece que debería usar 22R :) Además, sí, las trazas se modelaron para 90- diferencial de ohmios, y se mantuvieron cerca de la misma longitud. Cada uno mide aproximadamente una pulgada de largo. Cambian de las capas superiores a las inferiores justo en el detector del cargador, y el cambio vuelve justo en el microcontrolador.
El reflejo (donde sea que esté) va a una impedancia más baja (el reflejo está desfasado). Sugeriría que las dos señales de aspecto diferente son las dos direcciones de señalización diferentes.
@GregoryKornblum Tuve el mismo pensamiento. No hay nada más conectado a las líneas USB. Podría intentar usar las bibliotecas USB más nuevas de ST; ¿Quizás los que estoy usando tienen errores?
@ThePhoton. Gracias. Verificaré primero la teoría de la reflexión, porque puedo cambiar las resistencias más fácilmente que puedo soldar esas pequeñas almohadillas :)
Esas resistencias son probablemente la terminación en serie requerida por la especificación USB. De acuerdo con las especificaciones, deberían estar alrededor de 16R-33R (2.2 es definitivamente demasiado pequeño) para tener en cuenta las diferentes impedancias del cable USB. Esto puede causar problemas, pero es probable que no se muestren como lo que realmente ves (deberían ser más consistentes). Yo consideraría cambiarlos de todos modos.
Intente muestrear en el medio de la forma de onda: el diagrama de ojo se ve lo suficientemente bien como para decodificarlo correctamente.
¿Alguien puede explicar el origen y el significado de "diagrama de ojo"?
Gracias por el excelente enlace, @TomL. Nunca me había encontrado con eso antes.

Respuestas (3)

No parece que sea un problema de hardware. La forma de onda escalonada parece que está ocurriendo un reflejo o está en la transición cuando el host y el dispositivo cambian los roles de remitente y receptor. En cualquier caso, la señal se ve lo suficientemente buena como para ser decodificada correctamente.

Ayudaría si coloca el gatillo de su alcance en algún lugar de la pantalla. Con el disparador fuera de la pantalla, es posible que obtenga más fluctuaciones aparentes de las que realmente hay en cualquier bit.

Necesita mirar su software cuidadosamente. Lo más probable es que tenga un error en algún lugar que corrompa o pierda o agregue un byte cuando ocurre un caso de esquina particular. Esto podría ser, por ejemplo, durante la contienda por el FIFO cuando le falta un byte para completarse o algo así. Si se está accediendo al FIFO tanto por código de interrupción como de primer plano, entonces este es exactamente el tipo de problema difícil de encontrar que espera cuando la lógica de bloqueo no es del todo correcta.

Gracias, Olin. Resultó ser un error de software. La biblioteca USB de ST rellena la cola de salida un byte a la vez ( Buffer[index] = data; index++;). Cuando construí mi propia función, lo hice de esta manera: Buffer[index++] = data;Aparentemente, el proceso USB tendría lugar (muy ocasionalmente) después de que se incrementara el índice pero antes de que se escribieran los datos.

Esta es una señal FS absolutamente perfecta. Aparentemente, el OP prueba las señales en el extremo del dispositivo del cable. Las señales FS no están terminadas por el estándar USB. Todas las señales entrantes (controladas por host) están bien, ya que se miden en el punto de destino. Sin embargo, cuando el dispositivo devuelve un paquete de protocolo de enlace ocasional (ACK corto o NAK o de lo contrario), el controlador llega a la línea de transmisión. La señal de media amplitud (hombro) se desarrolla hasta que regresa el reflejo del extremo del host. Este es un comportamiento absolutamente normal de las señales en una línea de transmisión sin terminación. Como veo, el retraso de ida y vuelta es de unos 20 ns, o 10 ns de ida. Esto indica que el cable en uso tiene aproximadamente 2 m de largo o un cable estándar de 6 pies. Si el OP sondeara el bus en el extremo del host, vería una imagen opuesta. Solo mi 2c.

¡Excelente Ali, gracias! Esto es lo que estaba buscando. Lo siento, ya he aceptado una respuesta diferente...

Estoy enviando datos en paquetes de 254 bytes. De vez en cuando (con un promedio de 1 en 17000 paquetes) la computadora host recibe datos incorrectos. Generalmente está restringido a un solo byte en el paquete.

¿Utiliza un FIFO? Si es así, verifique su código fuente: hay malos ejemplos de FIFO que realmente permiten leer un byte "malo".

La "forma de onda incorrecta" todavía está dentro de las especificaciones. Probablemente vea un reflejo cuando la PC envía datos. Esto será mejor cuando use un concentrador o use puertos traseros de PC de escritorio, y peor en los puertos frontales que están conectados por cables más largos dentro de una PC.