Extrañas señales I2C emitidas desde FPGA

Tengo un dispositivo ZedBoard FPGA y estoy tratando de implementar una interfaz I2C para comunicarme con un módulo de cámara. Estoy usando Vivado 2014.2 y he agregado un bloque AXI IIC a mi diseño con la frecuencia de reloj SCL establecida en 90 KHz. Los pines físicos SCL/SDA tienen una resistencia pull-up de 10k a VCC (también probé 4K7). Por alguna razón, mi alcance muestra que ambos pines ya tienen algún tipo de señal no válida que se emite en ellos, cuando debería afirmarse bajo ya que aún no he configurado ninguna comunicación real en el software. ¡También observe que la velocidad de estas señales es de 24 MHz! Que resulta ser la velocidad del reloj del procesador integrado por alguna razón (no, los pines NO están mezclados). Aquí está la salida del osciloscopio con los pines SCL/SDA:

foto

¿Alguna idea de por qué sucede esto?

¿El bloque I2C necesita algún paso inicial de reinicio/configuración?
No, la señal debe ser plana hasta que le diga que escriba en un registro.
¿Cuál es la amplitud (v pico a pico) de las señales mostradas?

Respuestas (3)

Entonces, las señales no deseadas están sincronizadas pero no perfectamente idénticas (aunque ese podría ser el alcance) y alrededor de 1Vpp.

¿Diálogo, tal vez? ¿Hay otra señal sincronizada pero digital en un pin o rastro cercano? ¿Desaparecen las señales no deseadas si pones a tierra los pines en lugar de dejarlos flotando con pullups?

Si no incluye el módulo I2C en la compilación, ¿los pines exhiben el mismo comportamiento? Si incorpora algún GPIO conectado a esos pines y conduce los pines hacia arriba y/o hacia abajo, ¿la señal no deseada se superpone en el nivel lógico controlado o desaparece?

Además, ¿el bloque Zynq PS no tiene ya dos periféricos I2C? ¿Por qué no estás usando uno de ellos?

Sí, hay un pin de reloj de 24 MHz adyacente a las líneas SCL/SDA en el mismo conector PMOD, que es la entrada de reloj maestro para el módulo de la cámara (usando la salida PS FCLK). No he intentado conectar a tierra los pines... ¿Quiere decir conectar el pin SCL directamente a tierra sin la sonda pullup o de alcance? Los pines no exhiben el comportamiento sin el módulo. Incluso con el bloque I2C, no es hasta que se inicia el PS (que es cuando se enciende el FCLK) que hace esto. Probaré tu sugerencia de GPIO... ¿cómo solucionaría esto si se trata de diafonía? Sí, la PS ya tiene I2C, solo que aún no lo he probado.
Los relojes tienden a tener fugas, desafortunadamente. Si pudieras hacerlo diferencial eso ayudaría enormemente. Alternativamente, un amortiguador podría ayudar: una pequeña resistencia en serie con una pequeña tapa (digamos, 68R + 10pF) a tierra, colocada en el extremo receptor de la línea del reloj. Reconectando a tierra los pines, me refiero a llevarlos a tierra, ya sea con un trozo de cable o programando su lógica de accionamiento para generar un 0; De cualquier manera, dejaría los pullups en su lugar. Además, si se trata de un módulo comercial diseñado para conectarse al ZedBoard que causa problemas, ¿ha intentado preguntarle al proveedor?
Hmm, ¿tienes un enlace que explique cómo/por qué se filtran? Lamentablemente, la cámara no es compatible con un reloj diferencial y no está diseñada para ZedBoard, pero aquí está: goo.gl/5OEpGa . ¿Sería un factor el hecho de que el conector PMOD que estoy usando esté configurado como diferencial? ¿Ayudaría mover físicamente el reloj con fugas a otro pin/conector (y/o usar el PS I2C)?
La "fuga" (no muy técnica, pero una descripción precisa del comportamiento) es común en las señales con altas tasas de respuesta y es más notoria si son muy repetitivas y regulares; Los relojes son un buen ejemplo. Si el reloj no puede ser diferencial, entonces moviéndolo a un pin diferente y colocando trazas de tierra a cada lado de él (por ejemplo, haciendo que los pines relevantes salgan y bajándolos), más el amortiguador que mencioné para reducir la velocidad de giro, debería ayudar mucho
Intenté mover el problemático pin de reloj de 24 MHz "XCLK" a un PMOD diferente y poner rastros de tierra a su alrededor, lo que tal vez ayudó un poco: i.imgur.com/uOTKeBA.jpg pero conducir SCL a tierra todavía muestra el mismo patrón que el XCLK pin, ahora con muy poco voltaje: i.imgur.com/8Vfvwbx.jpg Intenté usar el bloque PS I2C pero la señal sigue apareciendo igual, aunque ahora puedo leer registros, pero los datos que obtengo están corruptos.

Me parece que no estás manejando activamente los pines SCL/SDA. Probablemente estén configurados como de alta impedancia de forma predeterminada en el flujo de bits y, por lo tanto, simplemente muestren el ruido del reloj del pin adyacente como han sugerido otros. Parece que el osciloscopio muestra 500 mv por división, por lo que la magnitud del ruido me parece grande, pero eso no lo descarta cuando está en alta impedancia, si su pullup no funcionaba.

Intente mirar el editor de pin/pad del dispositivo para asegurarse de que realmente tiene los pines activados como pines controlados. Verifique que los pines GND y de alimentación para el IO-Bank específico que contiene estos pines estén conectados en su placa y no flotando. Verifique que las conexiones verilog/vhdl estén intactas. Dependiendo de la cadena de herramientas FPGA del proveedor, busque la vista esquemática y busque el pin IO para asegurarse de que realmente esté controlado por algunos flip flops y que la señal del pin (el controlador de la celda IO para 'z' lógico) no es reemplazada por la constante 1.

Estoy seguro de que tan pronto como los controladores activos para estos pines estén habilitados, el ruido será completamente eclipsado por la señal.

El bloque AXI IIC está configurado para impulsar activamente los pines altos, y puedo decir por el osciloscopio que lo está haciendo, solo sigo viendo el ruido... el gnd/vcc del mismo conector pmod está conectado y no hay No hay ningún código HDL involucrado en este punto... No estoy seguro de cómo rastrear el flip flop, pero de alguna manera conseguí que 'funcionara' usando el controlador zynq I2C incorporado, aunque el ruido todavía está allí (pero no tanto).

Disculpe si esto es demasiado obvio, pero ¿tiene las sondas de alcance configuradas en 10: 1 y el límite de banda de 20MHz 'apagado' en el 'alcance?

Llegué un par de años tarde a esta fiesta, pero también agregaría que me asegure de que las conexiones a tierra de la sonda o-scope estén realmente conectadas a tierra, preferiblemente a través de un buen cable corto.
Extrañas señales I2C emitidas desde FPGA
RespuestasAquíPolítica de privacidad1y, 0v