El microcontrolador está siendo alimentado por la conexión UART

Tengo una placa ARM Cortex M3 personalizada que se comunica con una Raspberry Pi 4 a través de UART. Solo tres cables conectan el Pi a la MCU: Tx, Rx, GND. Cuando se apaga la fuente de alimentación de la MCU, el dispositivo no se apaga, pero consume 17 mA del pin Rx y puede llevar el riel de 3,3 V a 1,7 V, lo que es suficiente para mantener la MCU en funcionamiento, o al menos evitar que se reinicie. Presumiblemente, esto es a través de los diodos de protección cuando el suministro de 3.3V está apagado.

La Pi y la MCU funcionan con fuentes de alimentación independientes, pero están montadas en el mismo chasis y comparten una tierra. El cable UART tiene solo 10 cm de largo entre ellos.

¿Cuál es la forma correcta de aislar la energía entre estos dispositivos mientras se permite la comunicación UART? No necesito aislamiento galvánico, solo quiero evitar el reflujo de la fuente de alimentación. ¿Alguna sugerencia?

Actualmente tengo resistencias de 1 kΩ en serie con las líneas Rx y Tx, lo que evita que la MCU se encienda desde el Pi; sin embargo, todavía fluye corriente hacia el bus de 3.3 V y no sé si esto afectará negativamente los datos en serie.

(Editar: quiero enfatizar la naturaleza general de esta pregunta. Es común tener interconexiones push-pull entre dispositivos con interfaces como SPI, UART o simplemente bits GPIO. Todos estos tienen el potencial de alimentar energía a un dispositivo sin alimentación a través de los diodos de protección.)

¿Cuál es la tasa de baudios?
¿Por qué hay que aislar nada? Cuando la MCU se apaga, simplemente cambie la salida TXD que está conduciendo alta a baja o entrada. Esa es una solución de software que no requiere hardware.
La tasa de baudios es 115200, pero podría usar hasta 400 kbaudios si es estable.
El pin 8 de Raspberry Pi TX (GPIO14) suministra energía sin darse cuenta. No estoy seguro de si el UART se puede deshabilitar y si este pin maneja HighZ en el software. Además, Pi no sabe que la MCU está apagada.
Felicidades. Has captado el problema y ese es el 99% de la solución.
¿Puedes redirigir el UART a un pin que sea tolerante a 5V? ¿Tu MCU los tiene? Si es así, no tienen el diodo para la línea 3V3 (de lo contrario, no serían tolerantes a 5V...) Esto podría resolver su problema sin hardware adicional.
@DavidMolony Gracias, pero no creo que el IO tolerante a 5V ayude. En el STM32G4, los pines tolerantes a 5V de FT_c todavía tienen diodos de protección que se sujetan a VDD_FT, presumiblemente de una bomba de carga a 5V. Por otro lado, tal vez cuando la fuente VDD_FT se apague, evitará fugas a través del diodo hacia el VDD de apagado.

Respuestas (3)

Hay búferes que solucionarán esto (término de búsqueda: "ioff apagado parcial"). Siempre que el búfer se alimente desde el VCC de la placa Arm personalizado, bloqueará la corriente cuando el VCC esté ausente.

Pero también puedes arreglarlo con dos transistores, un PMOS como el BSS84 y un NMOS como el BSS138. Vea el esquema a continuación. Use V CC en su placa Arm personalizada para encender el BSS138. Esto, a su vez, encenderá el BSS84 para que la señal pueda pasar.

Pero cuando VCC no está presente, el BSS138 se apagará y luego el BSS84 también se apagará, y no puede fluir corriente de PI_TX a PI_TX_SW. Probablemente no se necesite R2. Probablemente ya haya algo entre VCC y GND que hará que VCC colapse.

Esta es la versión concisa de la respuesta porque estoy juzgando que su nivel de experiencia ya es bastante avanzado. Sin embargo, si lo desea, no dude en solicitar más detalles o aclaraciones en la sección de comentarios.

Si no es necesario ser frugal con el poder en el lado PI, puede cambiar R1 a 10 kohm más o menos.

esquemático

simular este circuito : esquema creado con CircuitLab

Esto funcionará bien siempre que VCC sea de 3,3 o 5 V. No funcionará de forma fiable con VCC = 1,8 V, por ejemplo.
+1 Solución genial. ¿R1 afectará la velocidad de conmutación?
Gracias, este es el tipo de solución que estaba buscando. Buscaré un búfer ioff que pueda hacer esto de forma llave en mano. Pensé que había una solución de transistor discreto simple, pero no pude resolverlo.
Estoy a punto de volver a hacer girar mi tablero ARM (si puedo encontrar alguna de las partes), así que me alegra saber la forma correcta de resolver este problema de aislamiento.
Los dos transistores serán de menor costo, pero el búfer es más fácil, más limpio y más compacto. El IC del paquete de búfer será tan pequeño como un transistor. Solo usaría los transistores si fuera un diseño de gran volumen O si los búferes no están disponibles debido a la escasez de piezas.
@devnull No lo creo. O no mucho. Creo que el límite de velocidad será la capacitancia del molinero en el BSS84. El problema con el 470k es que si hay alguna fuga de corriente en el BSS138, entonces tal vez el BSS84 comience a encenderse un poco cuando no queramos. Creo que 470k estará bien, pero no subiría mucho más.

La forma clásica es usar un "4050" ( ejemplo ) para amortiguar la señal entrante. Un 4050 no pasa energía de entrada a Vdd. Vdd debe conectarse a la alimentación de la placa M3. Hay muchos chips de "traductores de nivel" más modernos que también podría usar.

El 4050 podría comportarse de esta manera en la práctica, pero no veo nada en la hoja de datos que indique el tipo de comportamiento "Ioff" descrito por @mkeith arriba. Tal vez me perdí algo.
@Mike Vea la Figura 6 en la hoja de datos. A la entrada le falta el diodo a Vdd que normalmente está presente en CMOS. Ese diodo es el camino que sigue la energía pasiva.
Me pregunto si se usa el mismo diodo para la protección contra sobretensiones de 16 V con una ruptura inversa baja. Por supuesto, estos esquemas de hojas de datos son representativos del comportamiento, no de la implementación real.
@Mike Standard CMOS sujeta la sobretensión a los rieles de suministro a través de diodos. Un 4050 le hace eso al riel negativo, pero sí, usa la ruptura del diodo para el recorte positivo. Esto no es tan efectivo, y se sabe que los 4050 son algo más propensos a daños por ESD que los CMOS estándar.

Tal vez coloque un búfer no inversor de tres estados en la línea TX. Como un SN74AHC1G125 o similar. Use un pullup en /OE para el Pi y bájelo activamente con la MCU.

Esto suena como que podría ser el camino correcto a seguir. Pero, ¿el búfer sufre el mismo problema si Vin> Vcc cuando la MCU está apagada? Si OE=Lo, la salida está apagada, pero ¿la protección contra sobrevoltaje de entrada retroalimentará a VCC?
Para estar seguro, puede buscar 125 alternativas de búfer con funcionalidad Ioff como esta: farnell.com/datasheets/2192952.pdf Evita el flujo inverso cuando el VCC es bajo.
Los búferes diseñados para proporcionar aislamiento cuando están apagados usarán esta palabra mágica "ioff" o, a menudo, la frase mágica "ioff apagado parcial". Entonces, si el OP busca esas frases mágicas, seguramente seguirá la iluminación.
Simplemente mantenga el búfer alimentado y apague la salida con el pin OE.
¿Hay alguna razón para preferir un búfer con una función OE para esto? El 74LV1G06 debería funcionar igual de bien, ¿verdad? ti.com/lit/ds/symlink/sn74lvc1g06.pdf . Siempre que el ARM esté encendido, se permitirá la salida.
La cosa OE podría funcionar si mantiene el búfer encendido. En ese caso, no necesita IOFF. El búfer se alimenta desde el lado PI y el OE viene desde el lado de la placa de brazo personalizado. Si sigue la ruta IOFF, entonces alimenta el búfer desde el lado del brazo y no necesita OE. Creo que esta segunda opción es más limpia. Porque (supongo) vas a poner el amortiguador en el tablero del brazo. Con la opción IOFF, no necesita VCC del lado de PI en absoluto.
El microcontrolador está siendo alimentado por la conexión UART
RespuestasAquíPolítica de privacidad1y, 0v