Ist es möglich, einen Mikrocontroller mit Software physisch zu zerstören?


29

Annahmen:

  • Keine externe Schaltung angeschlossen (außer der Programmierschaltung, die wir für korrekt halten).
  • uC ist nicht fehlerhaft.
  • Mit Zerstörung meine ich, den blauen Rauch des Todes freizusetzen, nicht ihn in Software zu mauern.
  • Es ist ein "normales" uC. Nicht irgendein sehr seltsames 1-in-1-Million-Gerät für einen bestimmten Zweck.

Hat jemand schon einmal so etwas gesehen? Wie ist es möglich?

Hintergrund:

Ein Sprecher eines von mir unterstützten Meetups sagte, es sei möglich (und nicht einmal so schwer), dies zu tun, und einige andere stimmten ihm zu. Ich habe das noch nie gesehen und als ich sie fragte, wie es möglich ist, bekam ich keine richtige Antwort. Ich bin jetzt wirklich neugierig und würde gerne Feedback bekommen.


3
Der einzig mögliche Weg, um dies zu erreichen, ist IMO, wenn ein Pin physisch mit VCC / COM verbunden ist und dieser Pin so konfiguriert ist, dass er entgegengesetzt zu dem angesteuert wird, an dem er angeschlossen ist, was zu einem Überstrom führt. Aber das ist ein kombinierter HW / SW-Fehler.
Shamtam,

6
Viele Steuerungen verfügen über einen softwaregesteuerten Flash, der einem Verschleiß unterliegt. Würde Software, die den Speicher in kurzer Zeit aufgebraucht hat, als "Zerstörung" des Chips gelten?
Supercat

1
Abgesehen von der Beobachtung von @ supercat über EEPROM oder Flash Wear (es ist möglich, EEPROM in wenigen Minuten zu verschleißen), füge ich hinzu, dass es in vielen Fällen kaum einen Unterschied zwischen einem physisch zerstörten Gerät und einem gemauerten Gerät gibt ' Produkt. Wenn es zurück in die Fabrik muss, sieht es fast genauso aus.
Spehro Pefhany

1
Hüten Sie sich vor der Endlosschleife der n-ten Komplexität . Es gibt es schon seit Ewigkeiten ...
jippie

3
@Roh Ich habe bereits einen Chip verbrannt, weil der Hardware-Typ die Vcc- und GND-Pins auf der Platine vertauscht hat. (Ich denke, er dachte, dass der Chip ein Tropfen Ersatz war ... Es war nicht.) Es gab Rauch und verbranntes Plastik. Es dauerte nicht lange, aber der Draht kann dies anscheinend überleben.
Mishyoshi

Antworten:


20

Natürlich können Sie mit der HCF- Anweisung!

Das heißt, ich sage, das ist unmöglich ohne externe Schaltkreise, abgesehen von Strom und dergleichen.

Selbst wenn Sie einige nicht absichtlich fehlerhafte Verbindungen einschließen, wird dies möglicherweise nicht schaden: Wenn Sie alle gpios an eine Stromschiene binden, stellen Sie sie als Ausgang (an die gegenüberliegende Stromschiene) ein, der sehr viel Strom verbrauchen kann. Ein gpio-Pin ist wahrscheinlich gegen Kurzschluss geschützt und so passiert nichts Schädliches.

Das Design einer externen Schaltung, die den Chip nach Belieben zerstört, ist meiner Meinung nach auch nicht trivial. Das erste, was mir einfällt, ist ein Hochspannungsnetzteil, ein nmos und ein Widerstand:

schematisch

simulieren Sie diese Schaltung - Schema erstellt mit CircuitLab Wo:

  • ist die übliche Versorgung für das Mikro, etwa 3 V 3 bis 5 V oder was auch immer benötigt wirdVCC
  • HV ist eine Versorgung, deren Spannung weit über den absoluten Maximalwerten des Mikros liegt
  • D1 schützt Ihre wertvolle 3V3-Spannungsquelle
  • R1 zieht das Mosfet-Gate hoch, wenn das Mikro es nicht auf Masse hält
  • M1 ist der designierte Mörder

Die Bedienung ist einfach: Wenn das Mikro den GPIOx M1 loslässt, steigt Vcc an und Ihr Chip fängt Feuer. Beachten Sie, dass dies eine beschissene Einrichtung ist, zum Beispiel muss HV eingeschaltet werden, nachdem Sie besonders sicher sind, dass der GPIOx fest am Boden gehalten wird. Einige Transistoren mögen vielleicht keine -5V Vgs, und so weiter ... Aber Sie bekommen das Bild.


3
liebe die HCF Referenz.
Platzhalter

Hey, danke, dass du mir eine neue TV-Serie zum Auschecken gegeben hast!
OJFord

@OllieFord Ich bin nicht sicher, wovon Sie sprechen ...
Vladimir Cravero

1
@VladimirCravero de.wikipedia.org/wiki/Halt_and_Catch_Fire_(TV_series )
Renan

15

Haftungsausschluss: Supercat sagte das zuerst in einem Kommentar.

Tatsächlich ist es nicht möglich, die meisten MCUs physisch zu zerstören, aber es ist möglich, sie so lange zu tragen, bis eine Fehlfunktion auftritt und sie unbrauchbar wird. Ich habe Erfahrung mit dem MSP430 von TI.

Mit diesen MCUs kann der gesamte Blitz jederzeit neu programmiert werden. Es ist nicht nur möglich, den Flash zu tragen, indem er millionenfach neu geschrieben wird, bis er ausfällt, sondern der On-Chip-Flash-Programmiergenerator kann auch zu einem Ausfall des unteren Prozessors führen, wenn der Programmiergenerator falsch konfiguriert ist. Dies ist ein für die Programmierung zulässiger Frequenzbereich. Wenn Sie sich außerhalb dieses Bereichs (langsamer) befinden, kann die Programmierzeit übermäßig lang werden und zum Ausfall der Flash-Zellen führen. Nach nur wenigen hundert Zyklen ist es möglich, die Flash-Zellen zu "brennen", was einen dauerhaften Ausfall verursacht.

Bei einigen Modellen ist es auch möglich, den Kern zu übertakten, sodass er durch Erhöhen der internen Spannung schneller wird. Die MCU wird mit einer Spannung von 1,8 bis 3,6 V betrieben, der Kern selbst ist jedoch für eine Spannung von 1,8 V ausgelegt. Wenn Sie den Core auf einer 3,6-V-Stromschiene zu stark übertakten, während Sie alle I / Os umschalten, alle Peripheriegeräte aktivieren und mit einer Geschwindigkeit von 40 MHz (normal sind max. 25 MHz bei größeren Modellen) in einem kleinen geschlossenen Gehäuse arbeiten, kann dies zu Braten führen Kern wegen Überhitzung. Tatsächlich sagten einige Leute, dass sie diese Frequenzen erreicht haben (normalerweise fällt der DCO vorher aus und der Chip ist gerettet, aber gut ... vielleicht).

Probier es einfach?


nit-pick - Ich glaube, die meisten Flash-Dateien funktionieren garantiert nicht mehr als 10.000 Schreibvorgänge und nicht "Millionen". Wahrscheinlich nicht wert, behoben zu werden, da Sie einen Punkt machen.
gbulmer

2
Ah ... Flash Wear. Ich erinnere mich an das erste Mal, dass ich einen Fehler hatte, der zu ständigen Schreibvorgängen im EEPROM auf einem Bild führte. Es dauerte nur ungefähr 10 Sekunden. Ich brauchte ungefähr eine Minute, um zu begreifen, was passiert ist :-)
slebetman

6

Laut stackexchange - "Ist es wirklich eine schlechte Idee, einen MCU-Eingangspin frei zu lassen?"

Es beschreibt einige Umstände , unter denen ein Chip kann durch einen offenen Schaltungsstift beschädigt werden. Edit: Ein Beispiel für Spansion Analog- und Microcontroller-Produkte lautet:

4.1 Port-Eingang / Nicht verwendete digitale E / A-Pins
Es wird dringend empfohlen, die digitalen E / A-Pins nicht unverbunden zu lassen, solange sie auf Eingang geschaltet sind. In diesem Fall können diese Pins in einen sogenannten schwebenden Zustand übergehen. Dies kann zu einem hohen ICC-Strom führen, was den Energiesparmodi entgegensteht. Auch kann die MCU beschädigt werden.

Die Bedingung in dieser Frage sind genau offene Schaltkreisstifte.

Unsere Aufgabe ist es also, das vom Mai zu fahren, um den Stift zu beschädigen. Ich denke, das ist genug, um über das Backen hinauszugehen.

Ein in dieser Antwort identifizierter Mechanismus treibt einen Eingangsstift auf eine Mittelwertspannung, wobei die beiden komplementären Transistoren beide "ein" sind. In diesem Modus kann die Pin-Schnittstelle heiß werden oder ausfallen.

Ein Eingangsstift hat eine sehr hohe Impedanz und ist auch ein Kondensator. Vermutlich reicht die Kopplung zwischen benachbarten Stiften aus, um durch schnelles Umschalten benachbarter Stifte die Ladung auf den Eingangsstift zu treiben und ihn in diesen "heißen" Zustand zu bringen. Könnte die Hälfte der E / A-Pins, die in diesen Zustand getrieben werden, den Chip ausreichend erwärmen, um Schaden zu verursachen?

(Gibt es einen Modus, in dem die Kapazität eines offenen Cirrcuit-Pins wie ein Spannungsverdoppler verwendet werden kann? Hmm.)

Ich denke auch, dass schädlicher Blitz ausreicht. Ich denke, das ist schon schlimm genug, um den Chip unbrauchbar zu machen.

Es muss sich nicht nur um Flash handeln, sondern nur um die Seite, die die Vektoren Power-on, RESET usw. enthält. Das Limit auf einer einzelnen Seite kann einige zehn Sekunden dauern.

Ich hatte einen Hinweis, aber keine soliden Beweise), dass es für einige MCUs schlimmer sein könnte. Ich habe vor ein paar Jahren an einer Präsentation teilgenommen. Jemand fragte, warum Konkurrenten Teile mit viel höheren Flash-Schreibzyklen anboten. Der Moderator des (namentlich nicht genannten) großen MCU-Herstellers sagte, dass sie in ihren Flash-Speicherspezifikationen einen sehr viel konservativeren Ansatz verfolgen. Er sagte, dass ihre Garantie bei einer erheblich höheren Temperatur als der Industrienorm definiert wurde. Jemand fragte "na und". Der Sprecher sagte, dass einige Herstellerprodukte eine signifikant kürzere Lebensdauer für das Neuschreiben haben würden als ihre Teile bei den gleichen Temperaturen, wie sie verwendet wurden. Meine Erinnerung war, 5x würde <1x werden. Er sagte, es sei sehr nichtlinear. Ich habe das so verstanden, dass Programmieren bei 80 ° C statt 25 ° C eine "schlechte Sache" wäre.

Das Umschreiben des Flash-Speichers in Kombination mit einem sehr heißen Chip macht ihn möglicherweise auch in weniger als 10 Sekunden unbrauchbar.

Bearbeiten:
Ich denke, "den blauen Rauch des Todes freizusetzen" ist eine härtere Einschränkung als erforderlich. Wenn eine der folgenden Komponenten beschädigt werden könnte: RESET-Pin-Schaltung, Brown-Out-Detektor, Einschaltschaltung, RC- oder Quarzoszillator (und möglicherweise einige andere Schaltungen), würde der Chip unbrauchbar.

Wie andere angemerkt haben, würde das Unterbrechen des Blitzes auch den Blitz irreparabel töten.

"Rauch" klingt beeindruckend, aber weniger offensichtliche tödliche Angriffe sind immer noch tödlich und viel schwerer zu erkennen.


5

Eine mögliche Quelle für eine solche Zerstörung ist das SCR-Latchup, bei dem sich unbeabsichtigte (intrinsische) Transistoren in einem Chip zu einer Art TRIAC zusammenfinden, der dann viel Strom aufnehmen kann. Dadurch können Bonddrähte leicht durchgebrannt werden, und ich habe sogar Geräte mit Kunststoffummantelung gesehen, die sich aufgrund der erzeugten Wärme sichtbar verzogen haben.

Die typische Ursache ist das (auch vorübergehende) Ansteuern eines Eingangs über oder unter die Versorgungs- bzw. Erdungsschiene, aber ich vermute, dass dies passieren kann, wenn ein Eingang potentialfrei bleibt. Und es ist nicht schwer, sich eine Schaltung vorzustellen, bei der die Schwebefähigkeit des Eingangs durch Software gesteuert wurde (obwohl dies eine sehr dumme Sache wäre).


4

Es ist MÖGLICH, dass Software, die absichtlich für diesen Zweck geschrieben wurde und auf einen bestimmten Prozessor abzielt, das Übertakten bis zu dem Punkt erzwingen kann, an dem der Prozessor überhitzt. Vorausgesetzt natürlich, dass der Prozessor Software-konfigurierbare Taktsteuerregister enthält.

Es ist natürlich NICHT möglich, dass ALLE Prozessoren auf diese Weise beschädigt werden. Wenn das wahr wäre, wären Milliarden von Z80s, 6800s und 6502s auf der Strecke geblieben, als wir noch Maschinencode manuell eingaben und dabei viele zufällige Fehler machten.


2
Sie benötigen keinen Zugriff, um die Uhr zu konfigurieren. Sie müssen die Software nur so ausführen, wie es sich der CPU-Designer nicht vorgestellt hat. Hier ist ein Code, der versucht, die theoretischen 4 FLOPS pro Zyklus auf einem Prozessor der Intel Core-Serie zu erreichen: stackoverflow.com/questions/8389648/… . Es ist bekannt, dass dieser Code CPUs überhitzt.
Slebetman

1
Handelt es sich um "Power Virus" -Programme?
Davidcary

1
@davidcary, das ist ein brandneuer Begriff für mich. Ich bezog mich jedoch nicht auf eine Reihe von takthungrigen Anweisungen, sondern auf die tatsächliche Änderung der Taktrate (einige Prozessoren unterstützen die Software-Steuerung der Taktrate durch Manipulation von Steuerregistern) auf eine höhere Frequenz als die CPU oder deren Kühlkörper kann damit umgehen.
TDHofstetter

3

Dies ist mein Beitrag zur Zerstörung eines Mikrocontrollers mit so wenig Teilen wie möglich ...

Schalten Sie die Ausgangspins einfach auf einige kHz um!

Abhängig vom internen Fehlermodus sehen Sie möglicherweise immer noch keinen Rauch.

schematisch

simulieren Sie diese Schaltung - Schaltplan erstellt mit CircuitLab

--Bearbeiten, hinzugefügt 22. August--

Nun, ich glaube nicht, dass Sie einen Mikrocontroller mit den angegebenen Kriterien ruinieren können. Aber Sie können externe Schaltkreise mit dem falschen Code EINFACH ruinieren. Ein Beispiel, das mir in den Sinn kommt, ist ein einfacher Aufwärtswandler, den ich kürzlich entworfen habe. Durch einfaches Anhalten des Codes beim Debuggen kann ein Induktor über einen MOSFET kurzgeschlossen werden. POOF


2
Ich möchte nicht "That Guy" sein, sondern Assumption # 1: "No external circuitry connected"
Radian

1
Du bist "der Typ". Der Untertext dieser Antwort lautet: "Nein, so einen Chip kann man nicht ruinieren."
Daniel

2

In Bezug auf den normalen Benutzermodus-Code glaube ich nicht, dass Sie irgendetwas schreiben können, das den Chip beschädigt.

Ich erinnere mich jedoch an die Tage der Mikroprozessoren, die in weniger als einer Minute oder sogar Sekunden zerstört werden könnten, wenn der Kühlkörper abfallen würde. Dann fügten sie thermische Erkennungsschaltungen hinzu, die die Uhr herunterdrehen würden, wenn das Teil zu heiß würde. Da wir jetzt weit mehr Transistoren einsetzen können, als auf einmal verwendet werden können, können Chips mehr Wärme erzeugen, als der Kühlkörper abgeben kann, und es sind das Energiemanagement und die Wärmekreise, die ihn schützen. Zum Beispiel siehe Intel Turbo Boost 2.0. Daher scheint es durchaus möglich zu sein, einen Chip einzuschmelzen, wenn Sie in der Lage sind, die Grenze für das Energiemanagement und den Wärmekreislauf zu umgehen oder zu erhöhen. Wenn diese also von der Software gesteuert werden (keine Ahnung, möglicherweise ist ein BIOS-Update erforderlich?), Können Sie neben der integrierten GPU-Arbeit und der H.264-Hardware-Dekodierung und -Kodierung auch eine Reihe paralleler Do-nothing-Schleifen ausführen Alles andere, was der Chip auf einmal tun kann, bis der Chip überhitzt und den magischen blauen Rauch abgibt.


2

Ich bin mit den STM32-Prozessoren am besten vertraut, sodass diese für diese Familie am besten geeignet sind. Ähnliche Ansätze sind jedoch auch mit anderen Prozessoren möglich:

  1. Es gibt einen permanenten Schreibschutzmodus. Wenn Sie also dieses Bit und ein nutzloses Programm auf den FLASH programmieren, kann die MCU nie wieder verwendet werden. Ich weiß nicht, ob dies als "Bricking" gilt, aber es handelt sich um einen permanenten Hardware-Mechanismus.

  2. Die Programmierpins sind als GPIO umkonfigurierbar. Da der Clock-Pin vom Programmiergerät angesteuert wird, kann dies zu einem Kurzschluss führen. Höchstwahrscheinlich würde es diesen einzelnen Stift brechen, was als Programmierstift ziemlich schlecht wäre.

  3. Wie von dirkt erwähnt, können die PLLs verwendet werden, um den Prozessor zu übertakten. Dies kann möglicherweise zu einer Überhitzung oder anderen Schäden führen.


1

Wer hat jemals gesagt, dass das nicht versteht, wie kompliziert der Designprozess von solchen Chips ist. Das bedeutet nicht, dass es nicht zu Ausrutschern kommt und die Codeabdeckung der Regressionen und Eckfälle manchmal etwas übersieht, aber die Aussage, dass ALLE oder sogar die meisten Prozessoren diesen Fehler haben, ist logischerweise zweifelhaft.

Fragen Sie sich einfach, was passiert, wenn ein Over-Clocker die Timing-Anforderungen überschreitet (sofern er nicht überhitzt). Der Chip fällt aus und beschädigt möglicherweise den Speicher und sogar den Festplattenzugriff. Grundsätzlich startet der Prozessor jedoch erneut und führt das Betriebssystem sogar erneut aus, wenn die Beschädigung behoben ist. Welche Art von richtig entworfenem Mikrocode könnte möglicherweise MEHR Störungen verursachen als dieses Szenario? - sehr wahrscheinlich keine Antwort.

TLDR; Alle Prozessoren haben diesen Fehler - NICHT


Ich glaube, einige / die meisten Mikrocontroller-CPUs (nach Volumen, nicht nach Wert) sind nicht mikrocodiert. Widerspricht das Ihrer Annahme?
gbulmer

Nein, ob Sie einen Sequenzer oder eine festgelegte Zelle entwerfen, die Regressionen und Einschränkungen / Tests für das Design sind eng.
Platzhalter

Wenn eine blaue Rauchwolke auftreten würde, wäre die CPU auf die eine oder andere Weise überhitzt. Entweder durch Erleben einer sehr hohen Spannung, Erleben eines sehr hohen Stroms, Erleben einer umgekehrten Polarität oder auch durch Erleben von Transistoren, die mit einer zu hohen Frequenz schalten. In der Software ist nur die letzte Methode möglich. CPUs, die mit weniger als 500 MHz betrieben werden, sterben wahrscheinlich nicht aufgrund einer durch Software verursachten Überhitzung, aber ich habe gesehen, dass CPUs aufgrund einer durch Software verursachten Überhitzung sterben. Die Annahme, die Sie gemacht haben, ist genau das, was Sie nicht sollten.
Slebetman

@slebetman du bringst hier viel zu viele dinge zusammen. Wie kommt man durch Softwareanweisungen zu einer "Verpolung"? Wie kommt man zu "zu vielen Schaltvorgängen bei zu hoher Frequenz"? Gibt es vielleicht einen magischen Fehler in allen Chips, der sie zu massiv parallelen Ausführungspipelines macht?
Platzhalter

@placeholder: Ich sagte, Sie können die Polarität nicht durch Softwareanweisungen umkehren. Hast du meinen Kommentar gelesen?
Slebetman

1

Ich glaube, dass es durchaus möglich ist, einen Mikrocontroller (MC) mit Software physisch zu zerstören. Alles, was erforderlich ist, ist die Kombination des MC, um eine "enge" Schleife von Befehlen auszuführen, die eine 100% ige Auslastung bewirken, und einen "defekten" Kühlkörper, der es ermöglicht, dass sich die Wärme im Inneren des Chips aufbaut. Ob der Fehler Sekunden, Minuten oder Stunden dauert, hängt davon ab, wie schnell sich die Wärme aufbaut.

Ich habe einen Laptop, den ich nur zu 50% durchgehend nutzen kann. Wenn ich das überschreite, fährt sich der Computer herunter. Dies bedeutet, dass bei 50% Auslastung die MC-Temperatur unter dem eingestellten Triggerpunkt liegt. Mit zunehmender Nutzung steigt die Temperatur des MC, bis der Auslösepunkt erreicht ist. Wenn der thermische Abschaltkreis nicht funktionierte (oder keinen hatte), würde die Temperatur des MC weiter ansteigen, bis er zerstört würde.


0

schematisch

simulieren Sie diese Schaltung - Schaltplan erstellt mit CircuitLab

#include <avr/io.h>

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

Der obige Code bewirkt, dass die MCU PB2 nach oben drückt, während PB4 nach unten gezogen wird, und dies erzeugt einen Kurzschluss von VDD zu PB2 zu PB4 zu GND, und die Porttreiber von PB2 und / oder PB4 werden schnell braten. Der Kurzschluss kann ein unschuldiger Fehler wie eine versehentliche Lötbrücke sein.


Ich bin skeptisch, dass das funktionieren würde. IO-Pins können normalerweise keine großen Strommengen liefern oder ableiten. Die IO-Treibertransistoren würden den Strom begrenzen.
Adam Haun

@AdamHaun Das Problem ist, dass es keine Strombegrenzung gibt. Was hier passiert ist, dass diese Schaltung diese Transistoren verbrennen kann.
Maxthon Chan

Die Strombegrenzung ergibt sich aus der Größe und der Gate-Spannung der Ausgangstreibertransistoren. Möglicherweise könnten die Treiber durch einen 5-V-AVR durchgebrannt werden. Wenn Sie sich jedoch die ATMega-typischen Treiberstärketabellen ansehen und 3-Vcc-Kurzschlüsse zwischen zwei Pins vornehmen, überschreitet dies möglicherweise nicht einmal den absoluten maximalen Pin-Strom. Und der Strom sinkt mit hoher Temperatur! Niedrigere Leistungs-MCUs wären wahrscheinlich in Ordnung.
Adam Haun
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.