¿Es posible destruir físicamente un microcontrolador con software?

29

Suposiciones

  • No hay circuitos externos conectados (excepto el circuito de programación, que suponemos que es correcto).
  • uC no es defectuoso.
  • Al destruir me refiero a liberar el humo azul de la muerte, no taparlo en el software.
  • Es una uC "normal". No es un dispositivo específico muy extraño para 1 en un millón.

¿Alguien ha visto algo así? ¿Como es posible?

Fondo:

Un orador de una reunión a la que asistí dijo que era posible (y ni tan difícil) hacer esto, y algunas otras personas estuvieron de acuerdo con él. Nunca he visto que esto suceda, y cuando les pregunté cómo era posible, no obtuve una respuesta real. Tengo mucha curiosidad ahora, y me encantaría recibir algunos comentarios.

Juan Carlos
fuente
3
La única forma factible de que esto suceda, IMO, es si un pin está físicamente conectado a VCC / COM, y dicho pin está configurado para ser conducido opuesto a lo que está conectado, causando una condición de sobrecorriente. Pero esa es una falla combinada de HW / SW.
Shamtam
66
Muchos controladores tienen flash que se puede escribir bajo control de software y que está sujeto a desgaste. ¿El software que desgasta la memoria en un corto período de tiempo cuenta como "destruir" el chip?
supercat
1
Además de apoyar la observación de @ supercat sobre EEPROM o desgaste de flash (es posible desgastar EEPROM en unos minutos), agregaré que hay muy poca diferencia en muchos casos de un punto de vista del usuario entre un dispositivo físicamente destruido y un 'ladrillo' 'producto. Si tiene que volver a la fábrica, se ve más o menos igual.
Spehro Pefhany
1
Cuidado con el ciclo binario infinito de enésima complejidad . Ha existido durante siglos ...
jippie
3
@Roh Ya quemé un chip, porque el tipo de hardware cambió los pines Vcc y GND en la PCB. (Creo que pensó que el chip era una gota de reemplazo ... No lo era). Había humo y plástico quemado. No duró mucho, pero el cable puede sobrevivir a esto aparentemente.
Mishyoshi

Respuestas:

20

¡Por supuesto que puedes, con la instrucción HCF !

Dicho esto, digo que es imposible sin ningún circuito externo, aparte del poder y tal.

Incluso incluir algunas conexiones defectuosas no intencionadas posiblemente no sea suficiente: si conecta todos los gpios a un riel de alimentación, configurándolos como salida (al riel de alimentación opuesto) que puede disipar una gran cantidad de energía. Un pin gpio probablemente esté protegido contra cortocircuitos y, por lo tanto, no ocurrirá nada dañino.

Diseñar un circuito externo que destruya el chip a voluntad tampoco es trivial en mi opinión. Lo primero que viene a la mente necesita una fuente de alimentación de alto voltaje, un nmos y una resistencia:

esquemático

simular este circuito : esquema creado con CircuitLab donde:

  • es el suministro habitual para el micro, algunos 3v3 a 5V o lo que sea necesarioVCdo
  • HV es un suministro cuyo voltaje está muy por encima de las clasificaciones máximas absolutas del micro
  • D1 está ahí para proteger su valiosa fuente de voltaje 3V3
  • R1 tira de la puerta del mosfet alto cuando el micro no lo mantiene a tierra
  • M1 es el asesino designado

la operación es simple: si el micro libera GPIOx M1 se enciende, Vcc aumenta y su chip se incendia. Tenga en cuenta que esta es una configuración deficiente, por ejemplo, HV debe estar encendido después de estar seguro de que GPIOx está firmemente sujeto a tierra. Es posible que a algunos transistores no les gusten algunos VG de -5 V, y así sucesivamente ... Pero entiendes la imagen.

Vladimir Cravero
fuente
3
Me encanta la referencia de HCF.
marcador de posición
¡Hola, gracias por darme una nueva serie de televisión para ver!
OJFord
@OllieFord No estoy seguro de lo que estás hablando ...
Vladimir Cravero
15

Descargo de responsabilidad: supercat dijo eso primero en un comentario.

En realidad, no es posible destruir físicamente la mayoría de las MCU, pero es posible usarlo lo suficiente como para comenzar a funcionar mal hasta un punto donde no se puede usar. Tengo experiencia con el MSP430 de TI, así que aquí va:

Esas MCU permiten reprogramar todo el flash en cualquier momento. No solo es posible usar el flash reescribiéndolo millones de veces hasta que falle, sino que el generador de programación flash en el chip puede causar fallas en el procesador de gama baja si el generador de programación está configurado incorrectamente. Este es un rango de frecuencia permitido para la programación. Al salir de ese rango (más lento), el tiempo de programación puede ser excesivamente largo y provocar un fallo de las células flash. Después de unos pocos cientos de ciclos, es posible "quemar" las células flash causando fallas permanentes.

Además, algunos modelos permiten overclockear el núcleo para que alcance una mayor velocidad al aumentar el voltaje interno. El MCU funciona con un suministro de voltaje de 1.8-3.6V, pero el núcleo está diseñado para funcionar a 1.8V. Si overclockea demasiado el núcleo en un riel de alimentación de 3.6V mientras alterna todas las E / S, activa todos los periféricos y funciona a una velocidad de 40MHz (lo normal es un máximo de 25MHz en modelos más grandes) en una pequeña caja cerrada, puede terminar friendo el núcleo debido al sobrecalentamiento. En realidad, algunos chicos dijeron que lograron esas frecuencias (generalmente el DCO falla antes y el chip se guarda, pero bueno ... tal vez).

¿Solo inténtalo?

Mishyoshi
fuente
nit-pick: creo que se garantiza que la mayoría de las memorias flash funcionarán para no más de 10,000 escrituras, y no para "millones". Probablemente no valga la pena arreglarlo, ya que está haciendo un punto.
gbulmer
2
Ah ... Destello. Recuerdo la primera vez que tuve un error que causaba escrituras constantes en EEPROM en una foto. Todo lo que tomó fueron 10 segundos más o menos de tiempo de ejecución. Me tomó cerca de un minuto darme cuenta de lo que sucedió :-)
slebetman
6

De acuerdo a stackexchange: "¿Es realmente una mala idea dejar flotante un pin de entrada de MCU?"

Describe varias circunstancias en las que un chip puede dañarse con un pin de circuito abierto. Editar: un ejemplo Spansion Analog and Microcontroller Products dice:

4.1 Entrada de puerto / Pines de E / S digitales no utilizados
Se recomienda encarecidamente no dejar los pines de E / S digitales sin conectar, mientras se cambian a la entrada. En este caso, esos pines pueden entrar en el llamado estado flotante. Esto puede causar una alta corriente ICC, que es adversa a los modos de baja potencia. También puede ocurrir daño de la MCU.

La condición en esta pregunta es exactamente los pines de circuito abierto.

Entonces, nuestra tarea es conducir eso de mayo a va dañar el pasador. Creo que eso es suficiente para ir más allá del 'ladrillo'.

Un mecanismo identificado en esa respuesta es conducir un pin de entrada a un voltaje de valor medio, donde los dos transistores complementarios están ambos 'encendidos'. Operando en ese modo, la interfaz pin puede calentarse o fallar.

Un pin de entrada tiene una impedancia muy alta y también es un condensador. Presumiblemente, es suficiente el acoplamiento entre los pines adyacentes que al alternar los pines vecinos lo suficientemente rápido puede llevar la carga al pin de entrada y empujarlo a ese estado 'caliente'. ¿Podría la mitad de los pines de E / S que se conducen a ese estado calentar el chip lo suficiente como para causar daños?

(¿Existe un modo en el que la capacitancia de un pin de circuito abierto se pueda usar como un duplicador de voltaje? Hmm.)

También creo que dañar el flash es suficiente. Creo que es lo suficientemente malo como para inutilizar el chip.

No necesita ser todo flash, sino solo la página que contiene los vectores de encendido, RESET, etc. El límite en una sola página puede tomar algunas decenas de segundos.

Tenía una indicación, pero ninguna evidencia sólida) de que para algunos MCU podría ser peor. Asistí a una presentación hace un par de años. Alguien preguntó por qué los competidores ofrecían piezas con ciclos de escritura flash mucho más altos. El presentador (del gran fabricante de MCU sin nombre) dijo que adoptaron un enfoque mucho más conservador en sus especificaciones de memoria flash. Dijo que su garantía se definió a una temperatura significativamente más alta que la norma de la industria. Alguien preguntó "y qué". El orador dijo que los productos de varios fabricantes tendrían una vida útil de reescritura significativamente más baja que sus piezas a las mismas temperaturas que usaban. Mi recuerdo era 5x se convertiría en <1x. Dijo que es muy no lineal. Supuse que la programación a 80C en lugar de 25C sería una "cosa mala".

Por lo tanto, la reescritura flash combinada con un chip muy activo también podría volverlo inútil en menos de 10 segundos.

Editar:
Creo que "liberar el humo azul de la muerte" es una restricción más difícil de lo requerido. Si alguno de los siguientes: circuito RESET pin, detector marrón, circuito de encendido, RC u oscilador de cristal (y probablemente algunos otros circuitos) podría dañarse, el chip quedaría inútil.

Como otros han notado, romper el flash también lo mataría irreparablemente.

El "humo" suena impresionante, pero los ataques fatales menos obvios siguen siendo fatales y mucho más difíciles de detectar.

gbulmer
fuente
5

Una fuente potencial de tal destrucción es el latchup SCR, donde los transistores no intencionados (intrínsecos) en un chip se unen para formar una especie de TRIAC que luego puede absorber mucha corriente. Esto puede soplar fácilmente los cables de unión, e incluso he visto dispositivos de plástico encapsulados visiblemente debido al calor producido.

La causa típica es conducir (incluso momentáneamente) una entrada por encima o por debajo de los rieles de suministro o tierra respectivamente, pero supongo que es posible que suceda si una entrada se deja flotando. Y no es difícil imaginar un circuito en el que la flotabilidad de la entrada esté controlada por software (aunque sería algo muy tonto permitirlo).

tkp
fuente
4

Es POSIBLE que el software escrito intencionalmente para ese propósito, dirigido a un procesador muy específico, pueda forzar el overclocking hasta el punto en que el procesador se sobrecalentaría. Siempre que, por supuesto, el procesador contenga registros de control de reloj configurables por software.

NO es posible que TODOS los procesadores puedan dañarse de esta manera, por supuesto. Si eso fuera cierto, hubiera habido miles de millones de Z80 y 6800 y 6502 colocados en el camino por tiros de escritura de software rebeldes cuando todavía estábamos escribiendo código de máquina manualmente, cometiendo muchos errores aleatorios.

TDHofstetter
fuente
2
No necesita acceso para configurar el reloj. Solo necesita ejecutar el software de una manera que el diseñador de la CPU no imaginó. Aquí hay un código que intenta alcanzar los 4 FLOPS teóricos por ciclo en un procesador de la serie Intel Core: stackoverflow.com/questions/8389648/… . Se sabe que este código sobrecalienta las CPU.
slebetman
1
¿Está esto relacionado con los programas "power virus" ?
davidcary
1
@davidcary, ese es un término nuevo para mí. Sin embargo, no me refería a una serie de instrucciones que requieren mucho reloj, sino más bien a la alteración real de la velocidad del reloj (algunos procesadores admiten el control del software sobre la velocidad del reloj mediante la manipulación de los registros de control) a una frecuencia más alta que la CPU o su disipador de calor puede tratar con
TDHofstetter
3

Esta es mi entrada para arruinar un microcontrolador con la menor cantidad de piezas posible ...

¡Solo alterna los pines de salida a unos pocos kHz!

Sin embargo, es posible que aún no vea humo, dependiendo del modo de falla interna.

esquemático

simular este circuito : esquema creado con CircuitLab

--Editar, agregó el 22 de agosto--

Ahora, no creo que pueda arruinar un microcontrolador con los criterios dados. Pero puede arruinar FÁCILMENTE los circuitos externos con el código incorrecto. Un ejemplo que me viene a la mente es un convertidor de impulso simple que diseñé recientemente ... simplemente pausar el código mientras la depuración podría acortar un inductor a tierra a través de un MOSFET. MARICÓN

Daniel
fuente
2
No quiero ser "Ese tipo", pero suposición n. ° 1: "No hay circuitos externos conectados"
Radian
1
Estás siendo "Ese tipo". El subtexto de esta respuesta es "No, no puedes arruinar un chip así".
Daniel
2

En términos de código de modo de usuario normal, no creo que pueda escribir nada que rompa el chip.

Sin embargo, sí recuerdo los días de los microprocesadores que podrían destruirse en menos de un minuto o incluso segundos si el disipador de calor se cayera. Luego agregaron circuitos de detección térmica que apagarían el reloj si la parte se calienta demasiado. Ahora que podemos colocar muchos más transistores de los que se pueden usar a la vez, los chips son capaces de generar más calor del que puede disipar el disipador de calor y es la administración de energía y los circuitos térmicos que lo mantienen seguro. Por ejemplo, vea Intel Turbo Boost 2.0. Por lo tanto, parece bastante posible derretir un chip si puede evitar o elevar el límite en la administración de energía y el circuito térmico. Entonces, si estos están bajo control de software (ni idea; ¿tal vez requiere una actualización del BIOS?), Entonces podría ejecutar un montón de bucles paralelos de no hacer nada, junto con el trabajo integrado de GPU, junto con la decodificación y codificación de hardware H.264, y cualquier otra cosa que pueda hacer el chip, todo a la vez hasta que el chip se sobrecaliente y emita el mágico humo azul.

Dithermaster
fuente
2

Estoy más familiarizado con los procesadores STM32, por lo que se aplican más a esa familia. Pero enfoques similares pueden ser posibles con otros procesadores también:

  1. Hay un modo permanente de protección contra escritura. Entonces, si programa ese bit y algún programa inútil para FLASH, la MCU nunca podrá volver a usarse. No sé si esto cuenta como 'bloqueo', pero implica un mecanismo de hardware permanente.

  2. Los pines de programación son reconfigurables como GPIO. Debido a que el pin de reloj es accionado por el dispositivo de programación, esto podría usarse para causar un cortocircuito. Lo más probable es que rompa ese pin único, que ser un pin de programación sería bastante malo.

  3. Como mencionó dirkt, los PLL pueden usarse para overclockear el procesador. Esto podría causar que se sobrecaliente o se dañe.

jpa
fuente
1

¿Quién dijo que eso no comprende qué tan involucrado es el proceso de diseño de tales chips? Eso no significa que no ocurra un error y que la cobertura del código de las regresiones y los casos de esquina a veces se pierda, pero hacer una declaración de que TODOS o incluso la mayoría de los procesadores tienen este defecto es lógicamente dudoso.

Pregúntese qué sucede cuando un over-clocker excede los requisitos de tiempo (suponiendo que no se sobrecaliente). el chip falla y quizás daña la memoria e incluso el acceso al disco duro, pero fundamentalmente el procesador volverá a funcionar e incluso volverá a ejecutar el sistema operativo si se corrige el daño. Entonces, ¿qué tipo de microcódigo diseñado adecuadamente podría causar MÁS interrupción que este escenario? - Responda muy probablemente ninguna.

TLDR; Todos los procesadores tienen esta falla - NO

marcador de posición
fuente
Creo que algunas / la mayoría de las CPU de microcontroladores (por volumen, no por valor) no están microcodificadas. Entonces, ¿eso invalida su suposición?
Gbulmer
No, ya sea que esté diseñando un secuenciador o una celda de propósito fijo, las regresiones y restricciones / pruebas en el diseño serán estrictas.
marcador de posición
Para que se produzca una nube de humo azul, la CPU se habría sobrecalentado de una forma u otra. Ya sea experimentando un voltaje muy alto, experimentando una corriente muy alta, experimentando polaridad inversa o experimentando también, los transistores pueden cambiar a una frecuencia demasiado alta. Solo el último método es factible en software. Es poco probable que las CPU que funcionan a menos de 500MHz mueran debido al sobrecalentamiento del software, pero he visto que las CPU mueren debido al sobrecalentamiento del software. La suposición que hiciste es exactamente lo que no deberías.
slebetman
@Slebetman, estás combinando demasiadas cosas aquí. ¿Cómo se obtiene la "polaridad inversa" a través de las instrucciones del software? ¿Cómo se obtiene "demasiados cambios a una frecuencia demasiado alta"? ¿Existe quizás un defecto mágico en todos los chips que los convierten en tuberías de ejecución masivamente paralelas?
marcador de posición
@placeholder: Dije que no se puede obtener la polaridad inversa a través de las instrucciones del software. ¿Leíste mi comentario?
slebetman
1

Creo que ciertamente es posible destruir físicamente un microcontrolador (MC) con software. Todo lo que se requiere es la combinación del MC para ejecutar un ciclo "apretado" de instrucciones que provoque una utilización del 100%, y un disipador de calor "defectuoso" que permita que se acumule el calor dentro del chip. Si la falla demora segundos, minutos u horas, dependerá de qué tan rápido se acumule el calor.

Tengo una computadora portátil que solo puedo usar en un 50% de uso continuo. Si excedo esto, la computadora se apaga sola. Esto significa que con un 50% de uso, la temperatura del MC está por debajo del punto de activación establecido. A medida que aumenta el uso, la temperatura del MC aumenta hasta que se alcanza el punto de activación. Si el circuito de apagado térmico no funcionara (o no tuviera uno), la temperatura del MC seguiría aumentando hasta que se destruyera.

Guill
fuente
0

esquemático

simular este circuito : esquema creado con CircuitLab

#include <avr/io.h>

int main(void)
{
    DDRB |= _BV(2) | _BV(4);
    PORTB |= _BV(2);
    PORTB &= ~_BV(4);
    for (;;);
}

El código anterior hace que la MCU empuje PB2 alto mientras baja PB4, y esto crea un cortocircuito de VDD a PB2 a PB4 a GND y rápidamente los controladores de puerto de PB2 y / o PB4 se fríen. El cortocircuito puede ser un error inocente como un puente de soldadura accidental.

Maxthon Chan
fuente
Soy escéptico de que esto funcione. Los pines IO por lo general no pueden generar ni hundir grandes cantidades de corriente. Los transistores del controlador IO limitarían la corriente.
Adam Haun
@AdamHaun El problema es que no existe una limitación actual. Lo que está sucediendo aquí es que este circuito puede quemar esos transistores.
Maxthon Chan
La limitación de corriente es del tamaño y voltaje de la puerta de los transistores de accionamiento de salida. Tal vez un AVR de 5V podría quemar los controladores, pero al observar los cuadros de fuerza de controladores típicos de ATMega, con 3V Vcc que acorta dos pines juntos, incluso podría no exceder la corriente máxima absoluta del pin. ¡Y la corriente baja a alta temperatura! Las MCU de menor potencia probablemente estarían bien.
Adam Haun