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

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.

¡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:

^{simular este circuito : esquema creado con CircuitLab} donde:

• es el suministro habitual para el micro, algunos 3v3 a 5V o lo que sea necesario$V_{CC}$
• 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.

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?

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.

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).

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.

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.

^{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

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.

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.

¿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

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.

^{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.