Protección contra cortocircuitos de líneas de datos de alta velocidad

Necesito proteger las líneas de datos de un microcontrolador PIC32 (SPI y paralelo) que se ejecuta a ~10 MHz, contra cortocircuitos a tierra/Vcc o cableado incorrecto.

Usualmente (a bajas velocidades) uso resistencias en serie para limitar la corriente y funcionó bien, pero por supuesto esto no funciona ahora debido a la velocidad.

Estoy pensando en usar el búfer/inversor de línea (algo así como 74LVC04), esto salvará la MCU pero el búfer se dañará.

Busqué muchas familias lógicas (ACT, HCT, LVC, etc.), pero ninguna proporciona protección contra cortocircuitos.

¿Hay una solución mejor?

Editar después de los comentarios: esta es una placa de desarrollo para pruebas y validación, debido a errores de codificación, los pines pueden configurarse incorrectamente. o mal cableado, conectando la salida de MCU a la salida de destino en lugar de a la entrada.

Edición n. ° 2: ¡Un PTC ( 0603L004 ) podría ser una solución, sin embargo, es lento!

"Miswiring": entonces, este es un bus externo. Pasa por conectores? ¿A dónde va? ¿Cuál es la distancia? ¿Qué tipo de datos transportan allí? ¿Cuántas líneas paralelas?
Probablemente sea mejor describir su caso de uso, en general. "mal cableado" suena como algo que evitas usando conectores que no se pueden enchufar incorrectamente.
¿Revisaste el manual de referencia de los micros? Normalmente, el micro tendría su propia protección. ¿Estás tratando de proteger algo más que el micro?
@Marcus, edité la pregunta. Carlos el micro puede suministrar una cantidad abundante de 20 mA, pero no está protegido, por lo que no limitará la corriente.
Ah. Bueno, tal vez puedas configurar primero como IO. Luego configuran la salida brevemente y leen el resultado. Si se encuentra en 0 cuando maneja un 1 o 1 cuando maneja un 0, rechace activar el SPI.
buen truco gilberto :)
@CarlGilbert, solo lea la pregunta y habría publicado la 'prueba de manejo como E / S primero' como respuesta, pero veo que ya lo sugirió. Amplíe su comentario y publíquelo como una respuesta adecuada. Lo votaré.

Respuestas (6)

Los controladores CMOS tienen un límite de corriente inherente establecido por la resistencia de encendido de la fuente de drenaje de los FET del controlador de salida, Rds (encendido). Puede deducir esto de la hoja de datos basada en Vo (h) y Vo (l) para una corriente de salida dada.

Como ejemplo, la hoja de datos del PIC32 enumera Vo(l) como 0,36 V a 6 mA, lo que corresponde a un Rds(on) de 60 ohmios. Eso es una especie de conductor débil. Cortarlo a 3,3 V daría 55 mA, que es más de lo que permite la hoja de datos (16 mA), un límite bastante ajustado. Dicho esto, un cortocircuito en un pin no necesariamente dañará la pieza.

El mayor problema a menudo es el daño por ESD. Las cosas que se salen de la placa pueden beneficiarse de diodos TVS adicionales para aumentar la robustez de ESD.

mejor respuesta hasta ahora. Buen punto que planteó sobre el RDSon, ESD se puede administrar ya que hay muchos arreglos de TVS disponibles. Entonces, tal vez agregaría una pequeña resistencia en serie para que no afecte la velocidad (¿47 ohmios?), Pero ayudará a aumentar Rds On para garantizar que un cortocircuito no dañe la pieza, ¿qué piensas?
La resistencia en serie introduce una compensación entre la limitación y la velocidad. A 60 ohmios, la impedancia de salida es casi la adecuada para impulsar una traza de placa (60-65 ohmios típicos para una línea no controlada en una pila de 4L). Agregar más dará como resultado una falta de coincidencia en los casos de niebla y el tiempo de subida se verá afectado. .

OK, con toda honestidad: entonces el propósito de la placa de desarrollo es aprender a evitar estos errores.

Las soluciones a este problema particular (necesidad de comunicaciones externas de alta velocidad resistentes a errores) generalmente implican la transición a un bus de largo alcance específico.

Su "problema" tiene una "solución" que haría que su problema original, hablando con los periféricos, sea mucho más complejo que ya no es realmente una "solución".

Si su periférico puede destruir su controlador, tenga cuidado de no conectarlo incorrectamente. Por lo general, eso no es realmente difícil, en comparación con otras trampas de ingeniería. Por ejemplo, diseñaría una placa adaptadora que tenga un lado claramente etiquetado como "señal" y un lado etiquetado como "salida" y, si es posible, dos conectores diferentes en cada uno. Problema resuelto.

gracias por la respuesta, pero con fines de aprendizaje quiero estudiar una solución, no un paseo o prevención. tal vez un IC específico que resuelva mi problema simplemente. por ejemplo, hay muchos transceptores RS485 que tienen tales protecciones y más. Sin embargo, no he encontrado "todavía" algo similar para SPI o puertos paralelos
Pero no está aprendiendo nada sobre un problema del mundo real: en un diseño adecuado, los errores de cableado a bordo no son un problema. Si tiene un bus fuera del dispositivo, sí, algo como RS-485 es la solución adecuada. Pero no lo haces. Por lo tanto, no tener eso es la solución correcta aquí. Si desea obtener información sobre un autobús externo, debe especificar qué tipo de autobús (esas son todas las preguntas que hice en mi primer comentario debajo de su pregunta), luego decidirá qué tipo de autobús.
@ElectronS RS485 como topología está pensada para la red multipunto de larga distancia, por lo que se espera que los cables expuestos se conecten al equipo por casi cualquier Joe normal. Las interfaces como SPI suelen estar internamente orientadas a técnicos capacitados o semi-informados para cablear, o tienen conectores polarizados que solo van en una dirección.
@DmitriS, entiendo su punto En un producto terminado, esto no es un problema. pero considere lo siguiente, esta placa de desarrollo tiene los pines no utilizados conectados en un encabezado simple (como arduino), si otra persona quiere usar esta placa para probar su eeprom que tiene en una placa de prueba. fácilmente puede cablear algo de manera incorrecta y mi pregunta era sobre cómo evitar eso.
@ElectronS No creo que haya una solución a ese problema que no sea mucho más compleja que el sistema completo que tiene hasta ahora o que tenga una flexibilidad gravemente defectuosa. Estás tratando de resolver un problema que no es ninguno. Conector exclusivo con llave. Si lo conectan incorrectamente, realmente no es tu culpa. Si trabaja con productos electrónicos, debe realizar correctamente las conexiones básicas de bajo número de cables.
Tampoco encontré una solución, por eso pregunté aquí en el foro. ahora tengo mi respuesta gracias

Soy un ingeniero eléctrico. He trabajado en diseños basados ​​en microprocesadores de muchos productos. Ocasionalmente he conectado mal las cosas (más veces de las que me gustaría admitir). Además, en algún momento tenemos que entregar nuestro hardware a los ingenieros de firmware y también conectan las cosas mal todo el tiempo. Nunca he visto un GPIO frito debido a un cortocircuito a VCC o GND u otra salida. Obviamente, no recomiendo hacerlo a propósito, pero lo he hecho más veces de las que puedo contar, y los ingenieros de FW también lo han hecho mal. No creo que deba preocuparse por eso a menos que vaya a exponer la salida a un voltaje mayor que VCC o menor que GND.

Lo único que he hecho en ocasiones es usar lógica externa para asegurarme de que el equipo de FW no pueda crear accidentalmente un "estado prohibido". (Como encender el lado alto y bajo de un puente simultáneamente para crear disparos).

gracias, realmente gracias por reafirmar mi punto, que durante el desarrollo ocurre un error de cableado, especialmente si este no es un producto terminado y el cableado no está en un estado finalizado. Me siento aliviado de que el cortocircuito de GPIO no fríe el puerto o el chip.

El problema con los MCU modernos es el tamaño diminuto de los FET y las enormes tasas de aumento de la temperatura de calefacción local.

Recuerdo haber calculado dTemp/dTime de 1000 grados por microsegundo para esos (pequeños) FET, con muchos milivatios disipados en una o dos micras cuadradas, y la gran resistencia térmica de los cubos de silicio que tienen solo 1 micra por lado.

==================================

Para la protección contra sobretemperatura, cualquier sensor de temperatura debe estar dentro de las 10 micras del punto caliente. Si el punto caliente es un FET de salida submicrónica profundo, canal corto para un impulso alto, el FET puede autodestruirse antes de que se detecte una temperatura alta.

¿Solución práctica? A altas temperaturas, el FET se vuelve menos conductor. O detecte el exceso de temperatura y apague los FET (área costosa, para hacer eso).

Recuerdo historias de MCU de la era 1995 que se autodestruían cuando las salidas se acortaban.

Entonces, ¿quieres decir que no hay una solución práctica en el silicio? lo siento pero realmente no obtuve la respuesta

Una forma de proteger es aislar galvánicamente el bus de la MCU mediante el uso de aisladores digitales, por ejemplo . Estos funcionan bien a altas velocidades y son más fiables que, por ejemplo, los optoacopladores. También hay piezas especializadas diseñadas específicamente para SPI, I2C, etc.

Aunque esta solución se usa principalmente cuando espera que el secundario sea ruidoso y desea evitar que EMI, sobretensiones, corrientes de tierra y otras cosas desagradables golpeen su MCU directamente.

para que su solución funcione, los aisladores deben estar protegidos contra cortocircuitos; de lo contrario, esto no cambia nada

Quizás pueda configurar primero como IO. Luego configuran la salida brevemente y leen el resultado. Si se encuentra en 0 cuando maneja un 1 o 1 cuando maneja un 0, rechace activar el SPI.

También soy EE, pero sobre todo escribo software. Estoy de acuerdo con uno de los comentaristas anteriores que dijo que debe proteger todo lo que sale de la placa de ESD. Entonces, los diodos TVS definitivamente deberían estar presentes. Si alguno de los pines en el conector tiene más de 5 V, también debe proteger sus otros pines de ese voltaje más alto.