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

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.

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:

^{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 wird$V_{CC}$
• 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.

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?

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.

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).

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.

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.

^{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

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.

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.

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, 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.

^{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.