È possibile distruggere fisicamente un microcontrollore con il software?

ipotesi:

• Nessun circuito esterno collegato (diverso dal circuito di programmazione, che riteniamo corretto).
• uC non è difettoso.
• Distruggere intendo liberare il fumo blu della morte, non crearlo in mattoni nel software.
• È un uC "normale". Non è uno strano dispositivo specifico per 1 scopo su un milione.

Qualcuno ha mai visto accadere qualcosa del genere? Come è possibile?

Sfondo:

Un oratore di un incontro a cui ho assistito ha detto che era possibile (e nemmeno così difficile) farlo, e alcune altre persone erano d'accordo con lui. Non l'ho mai visto accadere e quando ho chiesto loro come fosse possibile, non ho avuto una vera risposta. Sono davvero curioso ora, e mi piacerebbe ricevere un feedback.

Certo che puoi, con l' istruzione HCF !

Detto questo, dico che è impossibile senza alcun circuito esterno, a parte il potere e simili.

Anche includere alcune connessioni non intenzionalmente difettose probabilmente non lo taglierà: se si collegano tutti i gpios a una power rail, impostandoli come output (alla power rail opposta) in grado di dissipare molta potenza. Un pin gpio è probabilmente protetto dal corto circuito e quindi non accadrà nulla di dannoso.

Secondo me, progettare un circuito esterno che distrugge il chip a piacimento non è banale. La prima cosa che viene in mente ha bisogno di un alimentatore ad alta tensione, un nmos e una resistenza:

^{simula questo circuito - Schema creato usando CircuitLab} Dove:

• è la normale fornitura per il micro, da 3v3 a 5V o qualsiasi altra cosa sia necessaria$V_{CC}$
• HV è un'alimentazione la cui tensione è ben al di sopra dei valori nominali massimi assoluti del micro
• D1 è lì per proteggere la tua preziosa fonte di tensione 3V3
• R1 tira in alto il cancello del mosfet quando il micro non lo tiene a terra
• M1 è il killer designato

l'operazione è semplice: se le micro release GPIOx M1 si accendono, Vcc aumenta e il tuo chip prende fuoco. Si noti che si tratta di una configurazione scadente, ad esempio HV deve essere acceso dopo aver verificato che GPIOx è saldamente bloccato a terra. Ad alcuni transistor potrebbe non piacere qualche Vg -5V, e così via ... Ma ottieni l'immagine.

Disclaimer: supercat lo ha detto prima in un commento.

In realtà, non è possibile distruggere fisicamente la maggior parte degli MCU, ma è possibile indossarlo abbastanza da iniziare a funzionare male fino a renderlo inutilizzabile. Ho esperienza con MSP430 di TI, quindi eccolo qui:

Questi MCU consentono di riprogrammare l'intero flash in qualsiasi momento. Non solo è possibile indossare il flash riscrivendolo milioni di volte fino a quando non si guasta, ma il generatore di programmazione flash su chip può causare guasti al processore di fascia bassa se il generatore di programmazione non è configurato correttamente. Questa è una gamma di frequenza consentita per la programmazione. Quando si esce da tale intervallo (più lentamente), il tempo di programmazione potrebbe allungarsi eccessivamente e causare un guasto delle celle flash. Dopo solo alcune centinaia di cicli, è possibile "bruciare" le celle flash causando guasti permanenti.

Inoltre, alcuni modelli consentono di overcloccare il core in modo che raggiunga una maggiore velocità aumentando la tensione interna. L'MCU funziona con una tensione di alimentazione di 1,8-3,6 V, ma il core stesso è progettato per funzionare a 1,8 V. Se si esegue l'overclocking eccessivo del core su una power rail da 3,6 V mentre si commutano tutti gli I / O, attivando tutte le periferiche e funzionando a 40MHz (in genere i modelli più grandi sono max 25MHz) in un piccolo caso chiuso, si potrebbe finire per friggere nucleo a causa del surriscaldamento. In realtà alcuni ragazzi hanno detto di aver raggiunto quelle frequenze (di solito il DCO fallisce prima e il chip viene salvato, ma bene ... forse).

Provaci e basta?

Secondo stackexchange - "È davvero una cattiva idea lasciare mobile un pin di input MCU?"

Descrive diverse circostanze in cui un chip può essere danneggiato da un pin di circuito aperto. Modifica: un esempio di Spansion Analog e Microcontroller Products dice:

4.1 Pin di I / O digitali in ingresso / inutilizzati della porta
Si consiglia vivamente di non lasciare i pin di I / O digitali scollegati mentre sono commutati in ingresso. In questo caso quei pin possono entrare in un cosiddetto stato mobile. Ciò può causare un'elevata corrente ICC, che è avversa alle modalità a bassa potenza. Inoltre, possono verificarsi danni all'MCU.

La condizione in questa domanda è esattamente i pin del circuito aperto.

Quindi, il nostro compito è quello di guidare che da maggio a sarà danneggiare il perno. Penso che sia abbastanza per andare oltre il "bricking".

Un meccanismo identificato in quella risposta sta guidando un pin di ingresso a una tensione di valore medio, in cui i due transistor complementari sono entrambi "attivi". Operando in quella modalità, l'interfaccia pin potrebbe surriscaldarsi o non funzionare.

Un pin di ingresso ha un'impedenza molto elevata ed è anche un condensatore. Presumibilmente, il loro è sufficiente accoppiamento tra i pin adiacenti che l'attivazione dei pin vicini abbastanza velocemente può condurre la carica sul pin di ingresso e spingerlo in quello stato "caldo". È possibile che metà dei pin I / O che vengono spinti in quello stato riscaldino il chip abbastanza da causare danni?

(Esiste una modalità in cui la capacità di un pin di circuito aperto potrebbe essere utilizzata come un duplicatore di tensione? Hmm.)

Penso anche che il danneggiamento del flash sia sufficiente. Penso che sia abbastanza brutto da rendere inutile il chip.

Non è necessario che sia tutto flash, ma solo la pagina che contiene i vettori di accensione, RESET ecc. Il limite su una singola pagina potrebbe richiedere alcune decine di secondi.

Ho avuto un'indicazione, ma nessuna prova concreta) che per alcuni MCU potrebbe essere peggio. Ho partecipato a una presentazione un paio di anni fa. Qualcuno ha chiesto perché i concorrenti offrissero parti con cicli flash molto più alti. Il presentatore (grande produttore senza nome MCU) ha affermato di aver adottato un approccio molto più conservativo nelle specifiche della memoria flash. Ha affermato che la loro garanzia è stata definita a una temperatura significativamente più elevata rispetto alla norma del settore. Qualcuno ha chiesto "e allora". Il relatore ha affermato che diversi prodotti dei produttori avrebbero una durata di riscrittura significativamente inferiore rispetto alle loro parti alle stesse temperature utilizzate. Il mio ricordo era 5x sarebbe diventato <1x. Ha detto che è molto non lineare. Ho pensato che la programmazione a 80 ° C anziché a 25 ° C sarebbe stata una "cosa negativa".

Quindi, la riscrittura del flash combinata con un chip molto caldo, potrebbe anche renderlo inutile in meno di 10 secondi.

Modifica:
Penso che "liberare il fumo blu della morte" sia un vincolo più difficile del necessario. Se uno qualsiasi dei circuiti di pin di RESET, rivelatore di brown-out, circuiti di accensione, oscillatore RC o di cristallo (e probabilmente alcuni altri circuiti) potrebbe essere danneggiato, il chip sarebbe reso inutile.

Come altri hanno notato, anche il rompersi del flash lo ucciderebbe irreparabilmente.

"Fumo" sembra impressionante, ma gli attacchi fatali meno evidenti sono ancora fatali e molto più difficili da rilevare.

Una potenziale fonte di tale distruzione è il latchup SCR, in cui transistor non intenzionali (intrinseci) in un chip si uniscono per formare una sorta di TRIAC che può quindi assorbire molta corrente. Questo può facilmente far saltare i fili di collegamento e ho persino visto i dispositivi di plastica incurvati visibilmente deformati a causa del calore prodotto.

La causa tipica è guidare (anche momentaneamente) un input sopra o sotto le guide di alimentazione o di terra rispettivamente, ma immagino che potresti vederlo accadere se un input fosse lasciato flottante. E non è poi difficile immaginare un circuito in cui la fluttuazione dell'ingresso era controllata da software (anche se sarebbe una cosa molto sciocca da consentire).

È POSSIBILE che il software scritto intenzionalmente allo scopo, mirato a un processore molto specifico, sia in grado di forzare l'overclocking fino al punto in cui il processore si surriscalderebbe. Naturalmente, a condizione che il processore contenga registri di controllo del clock configurabili tramite software.

Naturalmente NON è possibile che TUTTI i processori possano essere danneggiati in questo modo. Se ciò fosse vero, ci sarebbero stati miliardi di Z80 e 6800 e 6502 messi da parte da tirannici tirocinanti software-scrittura quando ancora stavamo digitando il codice macchina manualmente, facendo molti errori casuali.

Questa è la mia voce per rovinare un microcontrollore con il minor numero di parti possibile ...

Attiva / disattiva i pin di uscita a pochi kHz!

Potresti comunque non vedere il fumo, a seconda della modalità di guasto interno.

^{simula questo circuito - Schema creato usando CircuitLab}

--Modifica, aggiunto il 22 agosto--

Ora, non penso che tu possa rovinare un microcontrollore con i criteri indicati. Ma puoi FACILMENTE rovinare i circuiti esterni con il codice sbagliato. Un esempio che viene in mente è un semplice convertitore di boost che ho progettato di recente ... semplicemente mettere in pausa il codice mentre il debug potrebbe mettere in corto circuito un induttore per mettere a terra un MOSFET. POOF

In termini di codice in modalità utente normale, non penso che tu possa scrivere qualcosa che romperà il chip.

Tuttavia, ricordo i giorni dei microprocessori che potrebbero essere distrutti in meno di un minuto o addirittura secondi se il dissipatore di calore cadesse. Quindi hanno aggiunto circuiti di rilevamento termico che abbasserebbero l'orologio se la parte si surriscaldasse. Ora che siamo in grado di inserire molti più transistor rispetto a quelli che possono essere utilizzati contemporaneamente, i chip sono in grado di produrre più calore di quello che il dissipatore di calore può dissipare ed è la gestione dell'alimentazione e i circuiti termici che lo mantengono sicuro. Ad esempio, vedi Intel Turbo Boost 2.0. Pertanto sembra abbastanza possibile fondere un chip se si è in grado di bypassare o aumentare il limite sulla gestione dell'alimentazione e sul circuito termico. Quindi, se questi sono sotto il controllo del software (non ne hai idea; forse richiede un aggiornamento del BIOS?) Allora potresti eseguire un mucchio di cicli do-nothing paralleli, insieme al lavoro con GPU integrato, insieme alla decodifica e codifica H.264 hardware e qualsiasi altra cosa il chip può fare, tutto in una volta fino a quando il chip non si surriscalda ed emette il fumo blu magico.

Conosco molto bene i processori STM32, quindi questi si applicano soprattutto a quella famiglia. Ma approcci simili possono essere possibili anche con altri processori:

1. Esiste una modalità permanente di protezione dalla scrittura. Quindi, se programmate quel bit e qualche programma inutile su FLASH, l'MCU non potrà più essere usato. Non so se questo valga come "bricking", ma implica un meccanismo hardware permanente.

2. I pin di programmazione sono riconfigurabili come GPIO. Poiché il pin del clock è gestito dal dispositivo di programmazione, questo potrebbe essere usato per causare un cortocircuito. Molto probabilmente si spezzerebbe quel singolo pin, che essendo un pin di programmazione sarebbe piuttosto male.

3. Come menzionato da Dirkt, i PLL possono essere usati per overcloccare il processore. Ciò potrebbe causare il surriscaldamento o il danneggiamento.

Chi l'ha mai detto che non capisce quanto sia coinvolto il processo di progettazione di tali chip. Ciò non significa che lo slittamento non si verifichi e che la copertura del codice delle regressioni e dei casi angolari a volte manchi delle cose, ma affermare che TUTTI o anche la maggior parte dei processori hanno questo difetto è logicamente discutibile.

Basta chiedersi, cosa succede quando un overclocker supera i requisiti di temporizzazione (supponendo che non si surriscaldi). il chip fallisce e forse corrompe la memoria e persino l'accesso all'HDD, ma fondamentalmente il processore si riavvierà di nuovo ed eseguirà di nuovo il sistema operativo se la corruzione è stata riparata. Quindi, quale tipo di microcodice correttamente progettato potrebbe causare ulteriori interruzioni di questo scenario? - rispondere molto probabilmente a nessuno.

TLDR; Tutti i processori hanno questo errore - NON

Credo che sia certamente possibile distruggere fisicamente un microcontrollore (MC) con il software. Tutto ciò che serve è la combinazione dell'MC per eseguire un ciclo "stretto" di istruzioni che causano un utilizzo del 100% e un dissipatore di calore "difettoso" che consenta l'accumulo di calore all'interno del chip. Se il guasto richiede secondi, minuti o ore, dipenderà dalla velocità con cui si accumula il calore.

Ho un computer portatile che posso usare solo con un utilizzo continuo del 50%. Se lo supero, il computer si spegne automaticamente. Ciò significa che al 50% di utilizzo la temperatura MC è inferiore al punto di attivazione impostato. All'aumentare dell'utilizzo, la temperatura dell'MC aumenta fino al raggiungimento del punto di attivazione. Se il circuito di spegnimento termico non funzionasse (o non ne avesse uno), la temperatura dell'MC continuerebbe ad aumentare fino a quando non verrà distrutta.

^{simula questo circuito - Schema creato usando CircuitLab}

#include <avr/io.h>

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

Il codice sopra fa sì che l'MCU spinga PB2 in alto mentre tira PB4 in basso, e questo crea un cortocircuito da VDD a PB2 a PB4 a GND e rapidamente i driver della porta di PB2 e / o PB4 friggeranno. Il corto circuito può essere un errore innocuo come un ponte di saldatura accidentale.