Autor Tema: Sobrecalentamiento de chip MCP23S17 por sobreconsumo - Protegiendo GPIOs  (Leído 753 veces)

0 Usuarios y 1 Visitante están viendo este tema.

Desconectado genisuvi

  • PIC16
  • ***
  • Mensajes: 114
Buenos días,

Llevo unos días probando escrituras y lecturas de ese chip mediante un test de estrés que me he montado con python en una Raspberry 3. La idea es desarrollar una PCB con hasta 8 chips (Lo que permite su direccionamiento) de estos. El circuito lo tengo montado en una proto y es una versión básica con un único chip. Estoy poniendo a prueba el montaje más sencillo: 1 chip (clk spi funcionando a 1Mhz). Cabe decir que estoy tomando los 3.3V de los pines VDD de la Raspberry puesto que con un único chip el consumo no es prohibitivo.

EL test de python consiste en:
1.- configurar un banco como salidas y el otro como entradas con Rpull up habilitada.
2.- Las salidas escribirán siempre '0', nunca '1'.
3.- De entre todas las entradas algunas puede que estén directamente conectadas a alguna/s salida/s o bien no estar conectadas a nada, con lo cual leerán '0' o bien '1' (si están fotando/al aire).
4.- Las entradas también podrían estar durante la ejecución leyendo un contacto a GND (imaginad un usuario llevando una especie de "sonda" que lleva GND a las entradas GPIOs) o bien también puede ser un punto fijo (nadie lo cambia de posición) que está GND.

Ahora he probado qué tal se comporta en una proto teniendo 8 bits del chip de para entradas y otros 8 para salidas. Con un hilo a GND llevo GND a una de las entradas y con otros hilos juego a cerrar circuito conectando una entrada y una salida (con lo cual leería '0').

Problema:

Todo va perfecto hasta que ocurre que se dispara el consumo y se me calienta al punto de tocarlo y escaldarte. Le queda poco para quemarse. La cosa se resuelve si inmediatamente reseteo el chip. Levanto el pin de reset y se acabó. Luego vuelvo a arrancar y sigue leyendo bien sin recalentarse ni consumir fuera de lo habitual.



He consultado este tema y existe literatura que hace hincapié en estas posibles causas:

 * el switching en tecnología CMOS, en las que la prolongación en tiempo de un switcheo 0<->1 puede provocar enclavamientos y picos de corriente destructivos porque permanecería demasiado tiempo los dos transistores del inversor conduciendo. Esta es una de las principales causas del sobrecalentamiento indeseado. Por otro lado, pienso que leer "0-1" de forma prolongada -imaginad leer un tren de pulsos, palabras binarias de un bus- no puede ser que eso dañe un dispositivo por recibir en un pin '1' y '0' durante un tiempo no muy extenso, y, lo mismo, si así es no sé cómo protegen, de esto, a ese pin los diseñadores.


 * Diferencias o caídas de tensión diferentes puntos de GND --> no sé si tener hilos desde la Rasp hasta la proto afectaría mucho a eso.

 * Que esté llevando una tensión para Vih muy superior a VDD --> cosa imposible porque es el mismo chip el que escribe vih y escribe 3.3V. Igualmente no escribimos Vih, sino ViL siempre.

 * También hubo quien me sugirió también que una posible causa de este comportamiento podría ser "latch up" por ESD (un tiristor parásito) por el hecho que se arreglase al resetear el chip:

https://es.wikipedia.org/wiki/Enclavamiento_(electr%C3%B3nica) --> Pero no sé cómo protegerlas de ese fenómeno. Y me extraña ser la única a la que pase esto con tantos ejemplos de uso de este chip y conectándolo a circuitos más complejos. Nunca me había pasado esto.



Sugerencias de solución:

La gente me sugiere proteger con condensadores, Rs y diodos estas GPIOs; pero digo yo, no es exagerado meter en cada una de mis 64 GPIOs diodos, C y Rs? Más que nada porque no he visto ningún ejemplo de circuito que proteja así sus GPIOs (ni en MCUs ni en este chip en concreto), como mucho una R por si conectan por error una salida a un pulsador .

Yo no he visto esto ni con diodos, ni con condensadores y muchas veces ni si quiera Rs. Me gustaría saber cómo se suele proteger de una forma eficaz y eficiente las GPIOs. El circuito es muy sencillo, lo único es que tiene 64 puntos y se comunican con Rasp por SPI. Pero las GPIOs las usaré para cerrar circuito entre salida-entrada o las dejaré abiertas y leeré. No hay mucho más.

También me recomendaron usar Rs de 10K a las salidas y a las entradas. Yo lo he probado parece que no ha disparado el sobrecalentamiento (por ahora). Es cierto que estoy conectando y desconectando hilos durante la ejecución. Será ese el problema? Quizás los diseñadores no pongan condensadores ni diodos por que dan por hecho que no necesitarán proteger porque ven poco riesgo de cometer ciertos errores, o no conectarán cosas estando en marcha una ejecución, etc. Pero estos dispositivos que uso mantienen sus estados aunque se pare la ejecución. Y aunque un usuario no cambie conexiones de hilos hasta que no finalice la ejecución tengo miedo que esos cambios de hilos despierten a la fiera y se se achicharren las placas.


Sigo buscando ejemplos de circuitos con GPIO protegidas con diodos y condensadores para ver si me ilumino.

Agradecería si alguien me comparte su experiencia tratando GPIOs y protegiéndolas o bien sobre el tema de recalentamiento por sobreconsumo de este chip. Cualquier añadido será útil!
Gracias de antemano.



« Última modificación: 28 de Julio de 2020, 09:34:10 por genisuvi »

Desconectado elreypic2

  • Colaborador
  • PIC24H
  • *****
  • Mensajes: 1255
Re:Sobrecalentamiento de chip MCP23S17 por sobreconsumo - Protegiendo GPIOs
« Respuesta #1 en: 28 de Julio de 2020, 10:35:37 »
Definitivamente, el comportamiento que obtienes no es normal.
Es posible que exista algún problema con el código, ya que para que se caliente de esa manera, es porque se está creando un corto circuito que eleva la corriente y por eso el calentamiento.
Ya que si estuvieras activando todas las entradas al mismo tiempo a 0, y si estas tienen el pull-upo interno activado, la corriente que circula por cada entrada es extremadamente pequeña:

I = 3.3/100K = 33uA!!!
Si activas las 8, entonces sería 33uA x 8 = 264uA!!!! Eso no calentaría para nada al MCP23S017, por lo que estoy casi seguro que de alguna manera estás generando un corto. Y esto puede ser porque en tu código estés configurando el puerto de entrada como salida en un periodo de tiempo pequeño y eso obviamente alestar conectado a GND, estarías generando un corto por un periodo de tiempo pequeño, pero si este se hace oscilatorio, entonces de ahí la razón del problema.

Sería bueno que publicaras tu código de prueba para echarle una mirada.

elreypic.

Desconectado genisuvi

  • PIC16
  • ***
  • Mensajes: 114
Re:Sobrecalentamiento de chip MCP23S17 por sobreconsumo - Protegiendo GPIOs
« Respuesta #2 en: 28 de Julio de 2020, 17:37:54 »
Definitivamente, el comportamiento que obtienes no es normal.
Es posible que exista algún problema con el código, ya que para que se caliente de esa manera, es porque se está creando un corto circuito que eleva la corriente y por eso el calentamiento.
Ya que si estuvieras activando todas las entradas al mismo tiempo a 0, y si estas tienen el pull-upo interno activado, la corriente que circula por cada entrada es extremadamente pequeña:

I = 3.3/100K = 33uA!!!
Si activas las 8, entonces sería 33uA x 8 = 264uA!!!! Eso no calentaría para nada al MCP23S017, por lo que estoy casi seguro que de alguna manera estás generando un corto. Y esto puede ser porque en tu código estés configurando el puerto de entrada como salida en un periodo de tiempo pequeño y eso obviamente alestar conectado a GND, estarías generando un corto por un periodo de tiempo pequeño, pero si este se hace oscilatorio, entonces de ahí la razón del problema.

Sería bueno que publicaras tu código de prueba para echarle una mirada.

elreypic.

Muchas gracias por tu atención y aportación @elreypic2, sí ya sé que no debería calentarse ni mucho menos estar al punto de arder como Roma; quema cuando se dispara "lo que sea" que lo haga entrar en ese estado. Es más tenemos la fuente de la Rasp conectada a un dispositivo de estos que te muestra por display el consumo en watts y cuando esto sucede pasa de marcar 3.2Watts a 6watts! Así que hay un consumo destructible y anormal, un corto he pensado yo también. También, cuando eso ocurre, si mido en los pines de tensión de la Rasp que alimentan al chip hay una caída de 3.3V a 2.8V. Antes de que se me chamusque lo reseteo rápido.

Tengo que decir que yo arranco el programa y puede estar 2, 3, 4 horas seguidas y más funcionando sin problemas, con el mismo código que no es más que un loop que sólo lee un puerto y escribe por otro, básicamente. Usamos una librería de python así que el código que he escrito es de más alto nivel de abstracción. Donde llamo a funciones de inicialización (configura el control de los chips y las direcciones de los pines), otras 2 funciones; una de leer puerto y otra de escribir puerto disponibles en dicha librería. Pero de repente, se da esta situación. Algo dispara este sobreconsumo y no sabemos detectar qué es. Lo que hacemos es conectar algunas entradas a estas salidas que escriben '0' y vamos viendo (mostramos por pantalla) cómo va cambiando el valor del registro de 8 bits conforme va cambiando el '1' (de estar las entradas al aire con la Rpull up) por un '0'.

Intentando replicar el problema me pareció que se me disparó dos veces al momento de inyectar un hilo desde la salida en la fila del pin de la entrada. Al hacer la conexión, se producen rebotes hasta que se estabiliza el valor '0' de dicho pin. Hago reset y con el cable en la misma posición que tenía cuando se disparó el sobreconsumo al volver a ejecutar el sw de control, todo sigue OK. Funciona por horas correcto. Tampoco me parece normal que se dispare un cortocircuito en el driver del pin a causa del switching '1<-->0' de los rebotes. Digo yo que una entrada GPIO estará hecha para recibir un tren de pulsos, pulsos variados, formas típicas en un sinfín de aplicaciones (sensores, timers, interrupciones, etc) a menos que la arquitectura interna sea tan diferente (cosa que desconozco) entre los de estos chips y los GPIOs de cualquier uC/CI basado en tecnología CMOS.

Otro dato de interés -que a mí me haría pensar que el problema pueda no estar en el código- es que un compañero detectó el mismo recalentamiento, habiendo programado el control del sw con csharp; un código que leía lo que escribía por los pines de salida. Tampoco sabe decir si algo muy concreto lo disparaba; pero lo mismo: todo iba bien hasta que de repente se sobrecalentaba y disparaba el consumo. Reseteaba y vuelta a la normalidad por horas.

No te pongo mi código en python porque no estoy en el ordenador de la oficina y no tengo acceso ahora a él. Pero a mi regreso lo compartiré.

En lo que me insisten varias voces es que parece que se me esté dando el fenómeno del "latch up" por ESDs. Se forma una especie de tiristor parásito que deja a las dos uniones PNNP en conducción montando un corto y ya no lo desactivas a menos que apagues el chip o resetees. Y me comentan que debería proteger mis entradas frente a ese fenómeno. Me extraña de nuevo que las GPIO en modo entrada tengan esa posibilidad con el peligro de destrucción que supone. Sin embargo no veo este tipo de protecciones en otros proyectos similares. Como te digo no he visto más protección que Rs en serie en algunas GPIOs y sólo por si a caso alguien configura una salida como entrada si tiene conectados elementos para entradas tales como pulsadores, etc.
.
Así que no sé. La librería es Pi_MCP23S17.py -->https://github.com/jebentancour/Pi_MCP23S17
« Última modificación: 29 de Julio de 2020, 04:54:29 por genisuvi »

Desconectado Kid_Bengala

  • Colaborador
  • PIC18
  • *****
  • Mensajes: 441
Re:Sobrecalentamiento de chip MCP23S17 por sobreconsumo - Protegiendo GPIOs
« Respuesta #3 en: 30 de Julio de 2020, 17:44:32 »
Hola

No se si he entendido bien, pero eso de conectar salidas a entradas del circuito dependiendo como esten configuradas ¿no te puede estar provocando un corto? A mi me suena que en el curro para el amigo que trabajo tiene algun montaje con este circuito integrado en algun que otro pcb y lo ha usado para conmutaciones rapidas desde un software USB asi como para circuitos con cargas (creo que ataca mediante otra etapa de mosfet) y ha funcionado correctamente sin ningun problema de esos, se mantiene frio y sin consumo exagerado. Es para un sistema de debug que se reconfigura según la placa que se conecta (yo lo suelo usar para reparar algun equipo de otras compañias que cascan y lo desarrollo para hacer un chequeo ahorrando tiempo en reparaciones), tiene otra version con una fpga que hace mas funciones, pero han funcionado correctamente y no tiene diodos ni nada por el estilo, alguna resistencia si, pero no se si es para eso o que (no he mirado el esquema para saber si estan en los pines de I/O)

Tambien tiene otras placas con un micro similar de infineon, según el porque le gusta más esta marca para proyectos mas serios, por algo de ESD, por si te puede servir de referencia. Pero yo creo, según lo poco que se y lo que he visto con este integrado, que igual van por ahi los tiros, algun problema de reconfiguracion de las entradas/salidas.

Saludos !

Desconectado Sispic

  • Moderador Local
  • PIC24H
  • *****
  • Mensajes: 1532
    • winpic800
Re:Sobrecalentamiento de chip MCP23S17 por sobreconsumo - Protegiendo GPIOs
« Respuesta #4 en: 04 de Agosto de 2020, 03:31:09 »
puede ser que se configuren en algún momento las e/s erróneamente.
Para ello asegurarse 'no sé si ya lo haces' es verificar siempre los valores escritos en el registro .

algo asi :
Código: C
  1. /*******************************************************************/
  2. void Write_Byte_MCP23S17_L(int8 Addr , data){  
  3. /*******************************************************************/
  4.  
  5. spi_write_L(Addr,data);
  6.  
  7. /* VERIFICA */
  8.  if (spi_read_L(Addr) != data){
  9.   /* reintentar x intentos y si falla resetear MCP23S17 configurar todo lo necesario*/
  10.  }
  11.  
  12. }


Desconectado genisuvi

  • PIC16
  • ***
  • Mensajes: 114
Re:Sobrecalentamiento de chip MCP23S17 por sobreconsumo - Protegiendo GPIOs
« Respuesta #5 en: 04 de Agosto de 2020, 04:38:08 »
Hola

No se si he entendido bien, pero eso de conectar salidas a entradas del circuito dependiendo como esten configuradas ¿no te puede estar provocando un corto? A mi me suena que en el curro para el amigo que trabajo tiene algun montaje con este circuito integrado en algun que otro pcb y lo ha usado para conmutaciones rapidas desde un software USB asi como para circuitos con cargas (creo que ataca mediante otra etapa de mosfet) y ha funcionado correctamente sin ningun problema de esos, se mantiene frio y sin consumo exagerado. Es para un sistema de debug que se reconfigura según la placa que se conecta (yo lo suelo usar para reparar algun equipo de otras compañias que cascan y lo desarrollo para hacer un chequeo ahorrando tiempo en reparaciones), tiene otra version con una fpga que hace mas funciones, pero han funcionado correctamente y no tiene diodos ni nada por el estilo, alguna resistencia si, pero no se si es para eso o que (no he mirado el esquema para saber si estan en los pines de I/O)

Tambien tiene otras placas con un micro similar de infineon, según el porque le gusta más esta marca para proyectos mas serios, por algo de ESD, por si te puede servir de referencia. Pero yo creo, según lo poco que se y lo que he visto con este integrado, que igual van por ahi los tiros, algun problema de reconfiguracion de las entradas/salidas.

Saludos !


Están bien configuradas, además como digo se pasa horas funcionando perfectamente. Y lo otro sólo pasa muy esporádicamente; basta una sola vez para que se me frían los chips de una placa.
Por otro lado, estoy convencida que se produce enclavamiento (latch up). Después de leer más literatura sobre ese concepto "latch up" que consiste en un tiristor "fantasma" (parásito) creo que eso es lo que internamente se forma en ese pin, porque le haces un reset y vuelve al estado original. Sin cambiar nada, ni una coma del código, ni cableado, lo arrancas y sigue funcionando como si nada. Pero cuando se dispara no cambias la situación hasta que haces reset o le suprimes la alimentación.

No obstante ahora voy a comentar algo en lo que puede ser el cierre de este tema. Llevo varias días con el circuito en marcha y no se me ha dado más la situación. Comentaré en el hilo los cambios que he hecho y la lógica que creo que tiene.

Desconectado genisuvi

  • PIC16
  • ***
  • Mensajes: 114
Re:Sobrecalentamiento de chip MCP23S17 por sobreconsumo - Protegiendo GPIOs
« Respuesta #6 en: 04 de Agosto de 2020, 04:40:19 »
puede ser que se configuren en algún momento las e/s erróneamente.
Para ello asegurarse 'no sé si ya lo haces' es verificar siempre los valores escritos en el registro .

algo asi :
Código: C
  1. /*******************************************************************/
  2. void Write_Byte_MCP23S17_L(int8 Addr , data){  
  3. /*******************************************************************/
  4.  
  5. spi_write_L(Addr,data);
  6.  
  7. /* VERIFICA */
  8.  if (spi_read_L(Addr) != data){
  9.   /* reintentar x intentos y si falla resetear MCP23S17 configurar todo lo necesario*/
  10.  }
  11.  
  12. }

Sí, un compañero lee los registros con su código en cSharp. Son dos lenguajes distintos y tanto con Python como con cSharp ha estado pasando.
No obstante ahora os comento en el hilo un resumen de cómo tengo el tema ahora mismo y que creo que ya puedo ir cerrándolo.

Desconectado genisuvi

  • PIC16
  • ***
  • Mensajes: 114
Re:Sobrecalentamiento de chip MCP23S17 por sobreconsumo - Protegiendo GPIOs
« Respuesta #7 en: 04 de Agosto de 2020, 04:57:35 »
Comento la situación actual:

Llevo varios días después de unos cambios mínimos en que ese conflicto ha dejado de suceder.

Ya que al parecer la tecnología CMOS es sensible a los sobrepicos de tensión (esto favorecería la polarización de uniones PN/NP que no deberían estarlo y se ponen a conducir) cambié la fuente de alimentación del chip. En vez de emplear los pines de 3.3V de mi Raspberry estoy usando una fuente externa regulada. También le cambié un condensador de 1uF por uno de 0.1uF. Pensé que 1uF al ser más grande absorbería mejor que el de 0.1uF los sobrepicos. Igual, no sé si esta diferencia de orden de magnitud realmente ha podido influir tanto en evitar el corto interno (teoría que tengo, lo mismo no es así).

Por otra parte, después de indagar sobre el tema y conocer un poquito más parece ser otra causa de este tiristor parásito son las ESD, descargas electroestáticas bastante propias de entornos de laboratorio donde hay humanos con cargas, haciendo masa con el suelo trasteando y toqueteando. A mí esta opción no me parecería descabellada.


Ahora mismo tengo el circuito escribiendo 0-1 en bucle y desde que:

1.- no lo toco,
2.- uso fuente externa
3.- y un condensador más pequeño


eso ya no me ha sucedido más.

Si se me dispara, encuentro que al final hay una teoría más acertada que esta o puedo validar esta de una forma más contrastada lo comentaré.


Desconectado gustavopic

  • PIC16
  • ***
  • Mensajes: 114
Re:Sobrecalentamiento de chip MCP23S17 por sobreconsumo - Protegiendo GPIOs
« Respuesta #8 en: 04 de Agosto de 2020, 22:23:01 »
lo triste es que si pruebas con todo eso , no identificaras el origen y no lo podras "meter en tu cabeza como aprendizaje"

no te pareceria bueno  el ir probando de a uno estos cambios ??

1.- no lo toco,
2.- uso fuente externa
3.- y un condensador más pequeño

te quedara la duda siempre de que ? lo provoco y si esto mismo se te puede dar en una placa  de algo importante, por eso me parece interesante que le tomes el tiempo .
cosas que yo haria ?

yo buscaria provocar esa falla.

es lo bueno de un micro: lo podes programar:

1 -- un pin para un pulsador, que si lo pulsas te prenda un led y de paso te ponga todo en entradas  ( por ejemplo) .
NO meterle mano a el reset forzado.
con esta prueba te podras dar cuenta si el chip se colgo , o si sigue trabajando.
o bueno, un par de pienes para que un par de leds oscilen  asi ves realmente si el chip se colgo ( leds quietos ) o si el chip sigue corriendo .
y de paso : el pulsador para mandar todo como entradas, ( si no se ha colgado )

2 ---en cualquier caso , veria de activar el watch dog, no puede ser que se cuelgue con el wach dog o lo que se use hoy dia  activado.

3 --- si se cuelga de verdad y queda en ese estado , pues veria como sigo.
pero el tema es pescar eso , sino, ni cuenta te das y un dia lo repites con placas que sacas a al venta... y aunque se de eso cada 2 meses, basta 1 vez y chau.
« Última modificación: 04 de Agosto de 2020, 22:35:48 por gustavopic »

Desconectado genisuvi

  • PIC16
  • ***
  • Mensajes: 114
Re:Sobrecalentamiento de chip MCP23S17 por sobreconsumo - Protegiendo GPIOs
« Respuesta #9 en: 05 de Agosto de 2020, 09:49:32 »
lo triste es que si pruebas con todo eso , no identificaras el origen y no lo podras "meter en tu cabeza como aprendizaje"

no te pareceria bueno  el ir probando de a uno estos cambios ??

1.- no lo toco,
2.- uso fuente externa
3.- y un condensador más pequeño

te quedara la duda siempre de que ? lo provoco y si esto mismo se te puede dar en una placa  de algo importante, por eso me parece interesante que le tomes el tiempo .
cosas que yo haria ?

yo buscaria provocar esa falla.

es lo bueno de un micro: lo podes programar:

1 -- un pin para un pulsador, que si lo pulsas te prenda un led y de paso te ponga todo en entradas  ( por ejemplo) .
NO meterle mano a el reset forzado.
con esta prueba te podras dar cuenta si el chip se colgo , o si sigue trabajando.
o bueno, un par de pienes para que un par de leds oscilen  asi ves realmente si el chip se colgo ( leds quietos ) o si el chip sigue corriendo .
y de paso : el pulsador para mandar todo como entradas, ( si no se ha colgado )

2 ---en cualquier caso , veria de activar el watch dog, no puede ser que se cuelgue con el wach dog o lo que se use hoy dia  activado.

3 --- si se cuelga de verdad y queda en ese estado , pues veria como sigo.
pero el tema es pescar eso , sino, ni cuenta te das y un dia lo repites con placas que sacas a al venta... y aunque se de eso cada 2 meses, basta 1 vez y chau.

Pues vaya, yo intenté reproducirlo; pero no lo conseguí más. Tomaré en cuenta lo que dices.