¿Qué está mal con esta implementación de SPI?

Diseñé un sistema con RaspberryPi y STM32F407, comunicándose entre sí a través de interfaces SPI.

Durante los últimos 3 meses, las pruebas fueron correctas, pero ayer se quemaron una RaspberryPi y 2 de los puertos SPI de STM32F407. no sé por qué Todo estaba funcionando, me fui a dormir, todo estaba quemado por la mañana.

Aquí está el boceto de implementación:

Bosquejo de topología

Cuadros reales de los módulos

Los PCB tienen 15 cm de largo. Las líneas SPI son paralelas. No se utilizan líneas de selección de chips. No se utiliza resistencia de terminación. La frecuencia SPI es de 200 kHz. Las fuentes de alimentación son un cargador USB de 5V 1A para RaspberryPi, circuitos LM2576 de 3,3 V (implementados por mí mismo) que convierten 24 V a 3,3 V para MCU.

Conecté en caliente mis módulos alrededor de 10 veces sin ningún problema (¿por qué la conexión en caliente sería un problema con SPI?), aunque según el artículo de Wikipedia, SPI no es conectable en caliente.

  1. Entonces, ¿qué podría causar ese daño? ¿Ondas estacionarias? Conexión en caliente? ¿O tal vez la fuente de alimentación? ¿Cómo puedo encontrar la raíz de este problema?
  2. ¿Necesito usar aisladores ópticos (o búferes cmos) para cada unidad MCU?
¿A qué te refieres exactamente con "quemado"? ¿Hubo daño físico?
Así parece. El mcu de RaspberryPi estaba demasiado caliente para tocarlo.

Respuestas (1)

Tiene un bus SPI muy largo que se ejecuta en varios PCB. Esto no solo no se recomienda para SPI, sino que se diseñó originalmente para comunicaciones de chip a chip en una sola PCB, sino que lo tiene conectado directamente a sus CPU sin ningún tipo de búfer eléctrico.

Cualquier transitorio inducido (que podría incluir ESD durante la conexión en caliente) en cualquiera de las líneas de bus podría conducir fácilmente a cualquiera de sus CPU al "bloqueo CMOS", en el que se activa un SCR parásito que esencialmente corta Vdd a tierra. El daño físico por el aumento de temperatura resultante puede ser permanente.

SPI es particularmente fácil de almacenar en búfer, ya que cada una de las líneas es unidireccional. Debe incluir dichos búferes en la próxima revisión de cada uno de sus PCB.

¿Crees que cualquier amortiguador eléctrico (como 4050 o 74245 ) es suficiente o el aislamiento óptico es obligatorio?
No, no creo que necesites optoaislamiento. Cualquier amortiguador eléctrico clasificado para un nivel razonable de ESD debería estar bien.
He intentado almacenar en búfer con 4050 y MAX485 hasta ahora, pero no pueden transmitir con éxito la señal del reloj. Mañana probaré con otros circuitos integrados. Si entiendo correctamente, ¿no debo tener miedo de ESD si uso un búfer con protección ESD? Entonces puedo conectar en caliente mis módulos, ¿verdad?
No los dañará eléctricamente, pero hay otros problemas con su esquema de conexión en caliente. Dado que no usa las selecciones de chip, que normalmente proporcionan la alineación de bytes de los datos en el bus SPI, podría conectar un módulo en medio de una transacción, y estaría para siempre fuera de sincronización con el resto del sistema.
Usé 74HC244 para el almacenamiento en búfer y para las primeras pruebas estuvo bien. Conecté mi módulo en caliente varias veces y no hay nada quemado. El problema de sincronización no se observa en su mayoría, cuando ocurrió, mi software se encargó de ello. Pero luego, curiosamente, los búferes se queman. Los reemplacé, conecté mi módulo en caliente y luego todos los búferes se quemaron nuevamente. Me quedé sin chips de búfer, así que tendré que esperar hasta mañana para más pruebas.
Cuando conecta en caliente, ¿se asegura de que la conexión a tierra se conecte primero, luego Vcc y luego todas las líneas de datos?
No, es absolutamente aleatorio. Uso conectores DSUB-9, por lo que no puedo decidir el orden de conexión. Pero creo que entiendo la idea. Quiere decir que si conecto líneas de datos antes de VCC y si una línea es lógica 1, entonces puede ocurrir un bloqueo de cmos, ¿verdad? Si es así, puedo usar dispositivos TTL en el lado del bus y convertirlos a niveles CMOS en los lados de mcu. Creo que esto podría funcionar.
Leí algunos artículos y decidí que la conexión en caliente es otra historia. Necesito continuar sin la función de conexión en caliente y luego agregarla más tarde. Creo que detener la comunicación SPI durante la inserción del módulo es suficiente para evitar que el CMOS se enganche.
¿Qué está mal con esta implementación de SPI?
RespuestasAquíPolítica de privacidad1y, 0v