É possível destruir fisicamente um microcontrolador com software?

Suposições:

• Nenhum circuito externo conectado (exceto o circuito de programação, que assumimos estar correto).
• O uC não está com defeito.
• Destruindo, quero dizer liberar a fumaça azul da morte, não acumulá-la em software.
• É um uC "normal". Não é um dispositivo específico de propósito único muito estranho, de um em um milhão.

Alguém já viu algo assim acontecer? Como isso é possível?

Fundo:

Um orador de um encontro ao qual ajudei disse que era possível (e nem tão difícil) fazer isso, e algumas outras pessoas concordaram com ele. Nunca vi isso acontecer e, quando perguntei como era possível, não obtive uma resposta real. Estou muito curioso agora e gostaria de receber algum feedback.

Claro que você pode, com a instrução HCF !

Dito isto, eu digo que é impossível sem nenhum circuito externo, além de energia e coisas do tipo.

Mesmo incluindo algumas conexões com falha não intencional, possivelmente não será suficiente: se você amarrar todos os gpios a um trilho de potência, configurá-los como saída (no trilho de força oposto) que pode dissipar bastante energia. Um pino gpio provavelmente está protegido contra curto-circuito e, portanto, nada prejudicial acontecerá.

Projetar um circuito externo que destrói o chip à vontade também não é trivial na minha opinião. A primeira coisa que vem à mente precisa de uma fonte de alimentação de alta tensão, uma Nmos e um resistor:

^{simular esse circuito - esquema esquemático usando o CircuitLab} Onde:

• é o suprimento usual para o micro, alguns 3v3 a 5V ou o que for necessário$V_{CC}$
• HV é uma fonte cuja tensão está bem acima das classificações máximas absolutas do micro
• D1 está lá para proteger sua valiosa fonte de tensão 3V3
• R1 puxa o portão mosfet alto quando o micro não o mantém no chão
• M1 é o assassino designado

a operação é simples: se o micro libera o GPIOx M1, o Vcc aumenta e seu chip pega fogo. Observe que esta é uma configuração de baixa qualidade, por exemplo, a HV deve ser ligada depois que você tiver certeza absoluta de que o GPIOx está firmemente preso ao solo. Alguns transistores podem não gostar de -5V Vgs, e assim por diante ... Mas você entendeu.

Disclaimer: supercat disse isso primeiro em um comentário.

Na verdade, não é possível destruir fisicamente a maioria dos MCUs, mas é possível usá-lo o suficiente para começar a funcionar mal a um ponto em que ele não possa ser usado. Tenho experiência com o MSP430 da TI, então aqui vai:

Esses MCUs permitem reprogramar o flash inteiro a qualquer momento. Não apenas é possível usar o flash reescrevendo-o milhões de vezes até que ele falhe, mas o gerador de programação em flash no chip pode causar falhas no processador de ponta, se o gerador de programação estiver configurado incorretamente. Esse é um intervalo de frequência permitido para programação. Ao sair desse intervalo (mais lento), o tempo de programação pode se tornar excessivamente longo e causar uma falha nas células flash. Após apenas algumas centenas de ciclos, é possível "queimar" as células flash causando falha permanente.

Além disso, alguns modelos permitem fazer o overclock do núcleo para que ele atinja uma velocidade mais alta aumentando a tensão interna. O MCU funciona com fonte de tensão de 1,8-3,6V, mas o próprio núcleo foi projetado para funcionar com 1,8V. Se você overclockar demais o núcleo em um trilho de energia de 3,6V enquanto alterna todas as E / Ss, ativando todos os periféricos e funcionando a 40MHz (em geral, é o máximo de 25MHz em modelos maiores) em um pequeno gabinete fechado, você pode acabar fritando o núcleo por causa do superaquecimento. Na verdade, alguns caras disseram que atingiram essas frequências (geralmente o DCO falha antes e o chip é salvo, mas bem ... talvez).

Apenas tente?

De acordo com o stackexchange - "É realmente uma má idéia deixar um pino de entrada do MCU flutuando?"

Ele descreve várias circunstâncias nas quais um chip pode ser danificado por um pino de circuito aberto. Editar: um exemplo de produtos analógicos e microcontroladores da Spansion diz:

4.1 Entrada de porta / pinos de E / S digitais não utilizados
É altamente recomendável não deixar os pinos de E / S digitais desconectados enquanto estiverem na entrada. Nesse caso, esses pinos podem entrar no chamado estado flutuante. Isso pode causar uma corrente ICC alta, o que é adverso aos modos de baixa energia. Também podem ocorrer danos ao MCU.

A condição nesta pergunta é exatamente pinos de circuito aberto.

Então, a nossa tarefa é dirigir que a partir de Maio a irá danificar o pino. Eu acho que isso é suficiente para ir além do 'bricking'.

Um mecanismo identificado nessa resposta está direcionando um pino de entrada para uma tensão de valor médio, em que os dois transistores complementares estão "ligados". Operando nesse modo, a interface do pino pode esquentar ou falhar.

Um pino de entrada tem uma impedância muito alta e também é um capacitor. Presumivelmente, o acoplamento é suficiente entre os pinos adjacentes, e alternar os pinos vizinhos com rapidez suficiente pode carregar a carga no pino de entrada e empurrá-lo para o estado "quente". A metade dos pinos de E / S sendo acionados nesse estado pode aquecer o chip o suficiente para causar danos?

(Existe um modo em que a capacitância de um pino de circuito aberto possa ser usada como um dobrador de tensão? Hmm.)

Eu também acho que o flash prejudicial é suficiente. Eu acho que isso é ruim o suficiente para tornar o chip inútil.

Ele não precisa ser totalmente flash, mas apenas a página que contém os vetores Power-on, RESET etc. O limite em uma única página pode levar algumas dezenas de segundos.

Eu tinha uma indicação, mas nenhuma evidência sólida) de que, para alguns MCUs, pode ser pior. Eu assisti a uma apresentação alguns anos atrás. Alguém perguntou por que os concorrentes ofereciam peças com ciclos de gravação em flash muito mais altos. O apresentador (grande fabricante não identificado de MCU) disse que adotou uma abordagem muito mais conservadora nas especificações de memória flash. Ele disse que sua garantia foi definida a uma temperatura significativamente mais alta do que a norma da indústria. Alguém perguntou "e daí". O palestrante disse que vários produtos de fabricantes teriam uma vida útil de reescrita significativamente menor do que suas peças nas mesmas temperaturas que usavam. Minha lembrança era de 5x se tornaria <1x. Ele disse que é muito não linear. Entendi que a programação a 80 ° C em vez de 25 ° C seria uma "coisa ruim".

Portanto, a reescrita do flash combinada com um chip muito quente também pode torná-lo inútil em menos de 10 segundos.

Edit:
Eu acho que "liberar a fumaça azul da morte" é uma restrição mais difícil do que o necessário. Se algum dos circuitos de pinos: RESET, detector de queda de energia, circuito de inicialização, RC ou oscilador de cristal (e provavelmente alguns outros circuitos) puderem ser danificados, o chip ficará inútil.

Como outros observaram, quebrar o flash também o mataria irreparavelmente.

"Fumaça" parece impressionante, mas ataques fatais menos óbvios ainda são fatais e muito mais difíceis de detectar.

Uma fonte potencial dessa destruição é o travamento de SCR, onde transistores não intencionais (intrínsecos) em um chip se juntam para formar um tipo de TRIAC que pode então afundar muita corrente. Isso pode facilmente explodir os fios de ligação, e eu até vi dispositivos envoltos em plástico visivelmente deformados por causa do calor produzido.

A causa típica é direcionar (mesmo que momentaneamente) uma entrada para acima ou abaixo da fonte ou dos trilhos de aterramento, respectivamente, mas acho que você pode ver isso acontecer se uma entrada for deixada flutuando. E não é difícil imaginar um circuito em que a flutuação da entrada seja controlada por software (embora isso seja uma coisa muito boba de se permitir).

É POSSÍVEL que o software intencionalmente escrito para esse fim, direcionado a um processador muito específico, possa forçar o overclock até o ponto em que o processador superaqueça. Desde que, naturalmente, o processador contenha registros de controle de relógio configuráveis ​​por software.

NÃO é possível que TODOS os processadores possam ser danificados dessa maneira, é claro. Se isso fosse verdade, haveria bilhões de Z80s e 6800s e 6502s deixados de lado por erros de escrita de software rebeldes quando ainda estávamos digitando o código da máquina manualmente, cometendo muitos erros aleatórios.

Esta é a minha opinião por arruinar um microcontrolador com o mínimo de peças possível ...

Apenas alterne os pinos de saída em alguns kHz!

Você ainda pode não ver fumaça, dependendo do modo de falha interna.

^{simular este circuito - esquemático criado usando o CircuitLab}

--Edit, adicionado 22/08/08 -

Agora, acho que você não pode arruinar um microcontrolador com os critérios dados. Mas você pode facilmente arruinar os circuitos externos com o código errado. Um exemplo que vem à mente é um simples conversor de impulso que eu projetei recentemente ... simplesmente pausar o código durante a depuração pode causar um curto-circuito em um indutor para o aterramento através de um MOSFET. POOF

Em termos de código de modo de usuário comum, acho que você não pode escrever nada que possa quebrar o chip.

No entanto, lembro-me dos dias dos microprocessadores que poderiam ser destruídos em menos de um minuto ou até segundos se o dissipador de calor caísse. Depois, adicionaram circuitos de detecção térmica que reduziriam o relógio se a peça esquentasse demais. Agora que conseguimos colocar muito mais transistores do que os que podem ser usados ​​de uma só vez, os chips são capazes de produzir mais calor do que o dissipador de calor pode dissipar e são os circuitos térmicos e de gerenciamento de energia que o mantêm seguro. Por exemplo, consulte Intel Turbo Boost 2.0. Portanto, parece bem possível derreter um chip se você puder ignorar ou aumentar o limite no gerenciamento de energia e no circuito térmico. Portanto, se eles estiverem sob controle de software (não tem idéia; talvez exija uma atualização do BIOS?), Você pode executar vários loops paralelos sem fazer nada, juntamente com o trabalho integrado da GPU, juntamente com a decodificação e codificação do hardware H.264 e qualquer outra coisa que o chip possa fazer, de uma só vez, até que o chip superaqueça e emita a mágica fumaça azul.

Eu estou mais familiarizado com os processadores STM32, então eles se aplicam mais a essa família. Mas abordagens semelhantes podem ser possíveis com outros processadores também:

1. Existe um modo permanente de proteção contra gravação. Portanto, se você programar esse bit e algum programa inútil para o FLASH, o MCU nunca poderá ser usado novamente. Não sei se isso conta como 'bricking', mas envolve um mecanismo de hardware permanente.

2. Os pinos de programação são reconfiguráveis ​​como GPIO. Como o pino do relógio é acionado pelo dispositivo de programação, isso pode ser usado para causar um curto-circuito. Provavelmente quebraria esse pino único, o que seria um pino de programação muito ruim.

3. Como mencionado pelo dirkt, os PLLs podem ser usados ​​para fazer overclock no processador. Isso pode causar superaquecimento ou danos.

Quem nunca disse que isso não entende o quão envolvido o processo de design está desses chips. Isso não significa que o erro não ocorra e que a cobertura do código das regressões e casos de canto às vezes perca as coisas, mas afirmar que TODOS ou mesmo a maioria dos processadores tem essa falha é logicamente dúbio.

Apenas pergunte a si mesmo, o que acontece quando um contador de horas excede os requisitos de tempo (assumindo que não superaquece). o chip falha e talvez corrompa a memória e até o acesso ao disco rígido, mas fundamentalmente o processador será reiniciado novamente e até executará o sistema operacional novamente se a corrupção for corrigida. Então, que tipo de microcódigo projetado adequadamente pode causar MAIS interrupções do que esse cenário? - responda muito provavelmente nenhum.

TLDR; Todos os processadores têm essa falha - NÃO

Acredito que certamente é possível destruir fisicamente um microcontrolador (MC) com software. Tudo o que é necessário é a combinação do MC para executar um loop "rígido" de instruções que causam 100% de utilização e um dissipador de calor "defeituoso" que permite que o calor dentro do chip se acumule. Se a falha leva segundos, minutos ou horas, dependerá da rapidez com que o calor se acumula.

Eu tenho um laptop que só posso usá-lo com uma utilização contínua de 50%. Se eu exceder isso, o computador será desligado. Isso significa que, com 50% de uso, a temperatura do MC está abaixo do ponto de disparo definido. À medida que o uso aumenta, a temperatura do MC aumenta até que o ponto de disparo seja atingido. Se o circuito de desligamento térmico não funcionasse (ou não tivesse um), a temperatura do MC continuaria aumentando até ser destruída.

^{simular este circuito - esquemático criado usando o CircuitLab}

#include <avr/io.h>

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

O código acima faz com que o MCU empurre o PB2 alto enquanto puxa o PB4 para baixo, e isso cria um curto-circuito de VDD para PB2 para PB4 para GND e rapidamente os drivers de porta do PB2 e / ou PB4 fritam. O curto-circuito pode ser um erro inocente, como uma ponte de solda acidental.