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

Una fuente potencial de dicha destrucción es el bloqueo de SCR, donde los transistores no intencionados (intrínsecos) en un chip se juntan para formar un tipo de TRIAC que puede acumular mucha corriente. Esto puede dañar fácilmente los cables de unión, e incluso he visto dispositivos encapsulados de plástico visiblemente deformados 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 creo que podría ver que sucede si una entrada se deja flotando. Y entonces no es difícil imaginar un circuito en el que la entrada flotante fuera controlada por software (aunque eso sería algo muy tonto).

Es POSIBLE que el software escrito intencionalmente para este propósito, dirigido a un procesador muy específico, pueda forzar el overclocking hasta el punto en el que el procesador se sobrecalentaría. Por supuesto, siempre que 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, habría habido miles de millones de Z80 y 6800 y 6502 dejados a un lado por los informáticos que todavía escribían en el camino cuando todavía estábamos escribiendo el código de la 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 no veas humo, dependiendo del modo de falla interna.

^{simular este circuito : esquema creado usando CircuitLab}

--Editar, agregado el 22 de agosto--

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

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

Sin embargo, sí recuerdo los días de 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 reducirían la velocidad del reloj si la parte se calentara demasiado. Ahora que podemos instalar muchos más transistores de los que se pueden usar a la vez, los chips son capaces de generar más calor del que el disipador de calor puede disipar y su administración de energía y los circuitos térmicos lo mantienen seguro. Por ejemplo, consulte Intel Turbo Boost 2.0 . Por lo tanto, parece bastante posible derretir un chip si puedes evitar o aumentar el límite en la administración de energía y el circuito térmico. Entonces, si estos están bajo el control del software (¿no tiene 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 la 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 humo azul mágico.

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

1. Hay un modo permanente de protección contra escritura. Entonces, si programa ese bit y algún programa inútil para el FLASH, la MCU nunca podrá volver a usarse. No sé si esto cuenta como 'bricking', 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 se rompa ese único pin, que ser un pin de programación sería bastante malo.

3. Como mencionó dirkt, las 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 está el proceso de diseño de dichos chips? Eso no significa que no se produzca un deslizamiento y que la cobertura de código de las regresiones y los casos de esquina a veces se pierda, pero afirmar que TODOS o incluso la mayoría de los procesadores tienen esta falla es lógicamente dudoso.

Solo pregúntate, qué sucede cuando un over-clocker excede los requisitos de tiempo (suponiendo que no se sobrecaliente). el chip falla, y tal vez corrompe la memoria e incluso el acceso a la unidad de disco duro pero, fundamentalmente, el procesador se reiniciará de nuevo e incluso ejecutará el sistema operativo nuevamente si se soluciona la corrupción. Entonces, ¿qué tipo de microcódigo diseñado correctamente podría causar MÁS interrupciones que este escenario? - respuesta muy probable ninguno.

TLDR; Todos los procesadores tienen este fallo: NOT

Creo que es ciertamente posible destruir físicamente un microcontrolador (MC) con software. Todo lo que se requiere es la combinación del MC para ejecutar un ciclo de instrucciones "ajustado" que causa el 100% de utilización, y un disipador de calor "defectuoso" que permite que el calor dentro del chip construir. Si la falla lleva 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. Esto significa que al 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 disparo. Si el circuito de apagado térmico no funcionara (o no tuviera uno), la temperatura del MC continuaría aumentando hasta que se destruyera.

^{simular este circuito : esquema creado usando 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 presione PB2 alto mientras baja PB4, y esto crea un cortocircuito de VDD a PB2 a PB4 a GND y rápidamente los controladores de puertos de PB2 y / o PB4 se freirán. El cortocircuito puede ser un error inocente como un puente de soldadura accidental.