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

Question

Supuestos:

• Ningún circuito externo conectado (aparte de la programación del circuito, que suponemos ser la correcta).
• la uC no es defectuoso.
• Destruyendo me refiero a soltar el humo azul de la muerte, no bricking en software.
• Es un "normal" de la uC. No se muy raro 1-en-un-millón de propósito específico del dispositivo.

Alguien ha visto alguna vez algo como esto? ¿Cómo es posible?

Antecedentes:

Un altavoz de un meetup he asistido a dijo que era posible (y ni siquiera eso duro) para hacer esto, y algunas otras personas de acuerdo con él. Nunca he visto que esto suceda, y cuando les pregunté cómo era posible, no he tenido una respuesta real. Yo soy muy curioso y me gustaría obtener algunos comentarios.

Answer 1

Por supuesto, usted puede, con el HCF instrucción!

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

Incluso algunos no a propósito de conexiones defectuosas posiblemente no se corte: si usted atar todos los gpios a un carril de energía, estableciendo como salida (al contrario power rail) que puede disipar un buen montón de energía. Un pin gpio es, probablemente, protegidas contra cortocircuito y como por lo que nada malo va a suceder.

El diseño de un circuito externo que destruye el chip en la voluntad no es trivial demasiado en mi opinión. La primera cosa que viene a la mente las necesidades de un poco de suministro de alto voltaje, un nmos y una resistencia:

^{simular este circuito – Esquema creado mediante CircuitLab} Donde:

• $V_{CC}$ es el habitual de suministro para la micro, algunos 3v3 a 5V o lo que sea necesario
• HV es una oferta que el voltaje es muy por encima de los máximos absolutos de la micro
• D1 está ahí para proteger su valiosa 3V3 fuente de voltaje
• R1 tira de la mosfet de puerta de alta cuando el micro no es mantener a tierra
• M1 es el designado asesino

el funcionamiento es sencillo: si el micro versiones GPIOx M1 se enciende, Vcc se eleva y el chip se prende fuego. Tenga en cuenta que esto es una mierda de instalación, por ejemplo HV debe ser activado después de que usted es más que seguro que GPIOx está firmemente sujeta al suelo. Algunos transistores podría no como algunos -5V Vgs, y así sucesivamente... Pero usted consigue el cuadro.

Answer 2

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

En realidad, no es posible física destruir la mayoría de los Mcu, pero es posible usar es suficiente para iniciar el mal funcionamiento de un punto donde no se puede utilizar. Tengo experiencia con TI MSP430, así que aquí va:

Los Mcu permite la reprogramación de todo el flash en cualquier momento. No sólo es posible usar el flash de la reescritura es millones de veces hasta que falla, pero el chip de programación de flash generador puede causar una falla en la parte inferior del procesador si la programación del generador está configurado incorrectamente. Estos es un rango permitido de frecuencia permitido para la programación. Al llegar fuera de ese rango (más lento), el tiempo de programación puede volverse excesivamente largo y ocasionar un fallo del flash de las células. Después de sólo unos pocos cientos de ciclos, es posible "quemar" el flash de las células causando el error permanente.

Además, algunos modelos permite overclockear el núcleo de manera que se consigue una mayor velocidad al aumentar el voltaje interno. El MCU va desde 1.8-3.6 V alimentación de tensión, pero el núcleo en sí está diseñado para ejecutarse en el 1,8 V. Si overclock demasiado el núcleo en un 3,6 V power rail mientras se alterna todos los I/Os, la activación de todos los periféricos y se ejecuta en una llama de 40MHz (lo normal es max 25MHz en modelos más grandes) en un pequeño caso cerrado, usted puede terminar de freír el núcleo debido a un sobrecalentamiento. En realidad, algunos de los chicos dijo que alcanzaron esas frecuencias (generalmente el DCO falla antes y el chip se guarda, pero bueno... tal vez).

Acabo de probarlo?

Answer 3

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

Se describen varias circunstancias en las que un chip puede ser dañado por un circuito abierto pin. Edit: un ejemplo Spansion y Analógicas del Microcontrolador Productos dice:

4.1 Puerto De Entrada / Id Digital I/O Pins
Se recomienda no dejar digital I/O pins inconexas, mientras que se conectan a de entrada. En este caso los pines pueden entrar en un así llamado estado flotante. Esto puede causar un alto CPI actual, que es adverso a baja potencia los modos. También los daños de la MCU puede suceder.

La condición de esta pregunta es exactamente circuito abierto de patas.

Por lo tanto, nuestra tarea es la unidad que a partir de mayo para que se daño el pin. Creo que es suficiente para ir más allá de la "bricking'.

Uno de los mecanismos identificados en esa respuesta es la conducción de un pin de entrada a un valor medio de tensión, donde los dos transistores complementarios son tanto 'en'. Operativo en ese modo, el pin interfaz puede ser caliente o no.

Un pin de entrada tiene una impedancia muy alta, y es también un condensador. Presumiblemente, su es suficiente acoplamiento entre los pines que alternar vecinos pines lo suficientemente rápido posible de la unidad de carga en el pin de entrada y empuje en que 'hot' del estado. Quizás la mitad de los terminales de e/S siendo impulsado hacia el estado calentar el chip lo suficiente como para causar daño?

(Hay un modo en el que la capacitancia de un abrir cirrcuit pin puede ser utilizado como un doblador de voltaje? Hmm.)

Yo también creo dañar flash es suficiente. Creo que es lo suficientemente mala como para hacer que el chip inútil.

No tiene que ser todos los de flash, pero sólo la página que contiene el de encendido, RESET, etc vectores. El límite en una sola página puede tardar un par de decenas de segundos.

Tuve una indicación, pero no hay evidencia sólida de que para algunos de MCU del que puede ser peor. Asistí a una presentación de hace un par de años. Algunos se preguntaron por qué los competidores ofrecen piezas con mucho mayor de flash-writecycles. Los (grandes sin nombre MCU del fabricante) presentador dijo que tomó un enfoque más conservador en su memoria flash de especificaciones. Dijo que su garantía se define en un nivel significativamente más alto de la temperatura a la que fue la norma en la industria. Alguien le preguntó "para qué". El orador dijo que varios de los fabricantes de productos que tienen una menor de reescritura de la vida en los tiempos de sus piezas en el mismo temps, ya que utiliza. Mi recuerdo fue 5x sería <1x. Él dijo que es muy no lineal. Tomé, que a decir de programación en 80C en lugar de 25C sería una "cosa mala".

Así, flash reescritura combinado con un muy hot chip, también podría inutilizar en menos de 10 segundos.

Editar:
Creo que "soltar el humo azul de la muerte" es la más difícil de restricción de la requerida. Si alguno de los: pin RESET del circuito, (brown-out)-detector de encendido circuito RC o oscilador de cristal (y probablemente algunos otros circuitos) podría estar dañado, el chip sería inútil.

Como otros han señalado, rompiendo flash mataría de forma irreparable.

"Humo" suena impresionante, pero menos obvio fatales ataques todavía están fatal, y mucho más difícil de detectar.

Answer 4

Una fuente potencial de destrucción es SCR latchup, donde no deseados (intrínseco) de los transistores en un chip se juntan para formar una especie de TRIAC que puede, a continuación, fregadero de una gran cantidad de corriente. Esto puede fácilmente golpe de bonos de cables, e incluso he visto de plástico recubierto de dispositivos visiblemente deformada por el calor producido.

La causa típica es la de conducir (aunque sea momentáneamente) una entrada por encima o por debajo de la oferta o de raíles, respectivamente, pero supongo que se podría ver que sucede si una entrada se queda flotando. Y no lo es, es difícil imaginar un circuito donde la entrada flotante-ness fue controlada por el software (a pesar de que sería una tontería lo permiten).

Answer 5

Es POSIBLE que el software escrito intencionalmente para el propósito, dirigido a un muy procesador específico, podría ser capaz de la fuerza de overclocking hasta el punto en que el procesador sería un sobrecalentamiento. Siempre, claro está, que el procesador contiene software configurable por el reloj-los registros de control.

NO es posible que TODOS los procesadores pueden ser dañados de esta manera, por supuesto. Si eso fuera cierto, no he sido miles de millones de Z80s y 6800s y 6502s establecidas por el camino por díscolo software de escritura de tyros cuando estábamos aún a escribir en código de máquina manualmente, hacer un montón de errores aleatorios.