Est-il possible de détruire physiquement un microcontrôleur avec un logiciel?

Hypothèses:

• Aucun circuit externe connecté (autre que le circuit de programmation, que nous supposons correct).
• uC n'est pas défectueux.
• En détruisant, je veux dire libérer la fumée bleue de la mort, pas la bricker dans un logiciel.
• C'est une uC "normale". Pas un appareil très spécifique à un but très étrange.

Quelqu'un a-t-il déjà vu quelque chose comme ça se produire? Comment est-ce possible?

Contexte:

Un orateur d'une rencontre à laquelle j'ai assisté a dit qu'il était possible (et même pas si difficile) de le faire, et d'autres personnes étaient d'accord avec lui. Je n'ai jamais vu cela se produire, et quand je leur ai demandé comment c'était possible, je n'ai pas eu de vraie réponse. Je suis vraiment curieux maintenant et j'aimerais avoir des commentaires.

Bien sûr, vous pouvez, avec l' instruction HCF !

Cela dit, je dis que c'est impossible sans aucun circuit externe, en dehors de l'alimentation et autres.

Même en incluant des connexions non intentionnellement défectueuses, cela ne suffira probablement pas: si vous liez tous les gpios à un rail d'alimentation, en les définissant en sortie (sur le rail d'alimentation opposé), cela peut dissiper beaucoup de puissance. Une broche gpio est probablement protégée contre les courts-circuits et rien de tel ne se produira.

Concevoir un circuit externe qui détruit la puce à volonté n'est pas non plus trivial à mon sens. La première chose qui vient à l'esprit nécessite une alimentation électrique quelque peu haute tension, un nmos et une résistance:

^{simuler ce circuit - Schéma créé à l'aide de CircuitLab} Où:

• est l'alimentation habituelle pour le micro, certains 3v3 à 5V ou tout ce qui est nécessaire$V_{CC}$
• HV est une alimentation dont la tension est bien supérieure aux valeurs maximales absolues du micro
• D1 est là pour protéger votre précieuse source de tension 3V3
• R1 tire la porte mosfet vers le haut lorsque le micro ne la maintient pas à la terre
• M1 est le tueur désigné

l'opération est simple: si le micro libère GPIOx M1 s'allume, Vcc monte et votre puce prend feu. Notez qu'il s'agit d'une configuration merdique, par exemple, HV doit être activé après avoir vérifié que GPIOx est fermement maintenu à la terre. Certains transistors peuvent ne pas aimer certains Vgs -5V, et ainsi de suite ... Mais vous obtenez l'image.

Avertissement: Supercat l'a dit en premier dans un commentaire.

En fait, il n'est pas possible de détruire physiquement la plupart des microcontrôleurs, mais il est possible de le porter suffisamment pour commencer à mal fonctionner à un point où il est inutilisable. J'ai de l'expérience avec le MSP430 de TI, alors voici:

Ces MCU permettent de reprogrammer le flash entier à tout moment. Non seulement il est possible de porter le flash en le réécrivant des millions de fois jusqu'à ce qu'il échoue, mais le générateur de programmation flash sur puce peut provoquer une défaillance du processeur bas de gamme si le générateur de programmation est mal configuré. Il s'agit d'une plage de fréquences autorisée pour la programmation. Lorsque vous sortez de cette plage (plus lentement), le temps de programmation peut devenir excessivement long et provoquer une défaillance des cellules flash. Après seulement quelques centaines de cycles, il est possible de "brûler" les cellules flash provoquant une défaillance permanente.

De plus, certains modèles permettent d'overclocker le noyau afin qu'il atteigne une vitesse plus élevée en augmentant la tension interne. Le MCU fonctionne à partir d'une alimentation de 1,8 à 3,6 V, mais le noyau lui-même est conçu pour fonctionner à 1,8 V. Si vous overclockez trop le cœur sur un rail d'alimentation de 3,6 V tout en basculant toutes les E / S, en activant tous les périphériques et en fonctionnant à une vitesse fulgurante de 40 MHz (la normale est de 25 MHz maximum sur les modèles plus grands) dans un petit boîtier fermé, vous risquez de faire frire le noyau en raison de la surchauffe. En fait, certains gars ont dit qu'ils avaient atteint ces fréquences (généralement le DCO échoue avant et la puce est enregistrée, mais bon ... peut-être).

Essayez-le?

Selon stackexchange - "Est-ce vraiment une mauvaise idée de laisser une broche d'entrée MCU flottante?"

Il décrit plusieurs circonstances dans lesquelles une puce peut être endommagée par une broche de circuit ouvert. Edit: un exemple de produits analogiques et microcontrôleurs Spansion dit:

4.1 Port d'entrée / broches d'E / S numériques inutilisées
Il est fortement recommandé de ne pas laisser les broches d'E / S numériques non connectées pendant qu'elles sont commutées en entrée. Dans ce cas, ces broches peuvent entrer dans un état dit flottant. Cela peut provoquer un courant ICC élevé, ce qui est défavorable aux modes de faible puissance. Des dommages au MCU peuvent également se produire.

La condition dans cette question est exactement des broches de circuit ouvert.

Ainsi, notre tâche est de conduire que de mai à s'endommager la broche. Je pense que cela suffit pour aller au-delà de la «brique».

Un mécanisme identifié dans cette réponse est de conduire une broche d'entrée à une tension de moyenne valeur, où les deux transistors complémentaires sont tous les deux "passants". En fonctionnant dans ce mode, l'interface des broches peut devenir chaude ou échouer.

Une broche d'entrée a une très haute impédance et est également un condensateur. Vraisemblablement, leur couplage suffisant entre les broches adjacentes permet de basculer les broches voisines assez rapidement pour entraîner la charge sur la broche d'entrée et la pousser dans cet état «chaud». La moitié des broches d'E / S entraînées dans cet état peut-elle réchauffer suffisamment la puce pour l'endommager?

(Existe-t-il un mode où la capacité d'une broche de cirrcuit ouverte peut être utilisée comme un doubleur de tension? Hmm.)

Je pense aussi que le flash dommageable suffit. Je pense que c'est déjà assez mauvais pour rendre la puce inutile.

Il n'a pas besoin d'être entièrement flash, mais uniquement la page qui contient les vecteurs Power-on, RESET etc. La limite sur une seule page peut prendre quelques dizaines de secondes.

J'avais une indication, mais aucune preuve solide) que pour certains MCU, cela pourrait être pire. J'ai assisté à une présentation il y a quelques années. Quelqu'un a demandé pourquoi les concurrents proposaient des pièces avec des cycles d'écriture flash beaucoup plus élevés. Le présentateur (du grand fabricant de MCU anonyme) a déclaré avoir adopté une approche beaucoup plus conservatrice dans ses spécifications de mémoire flash. Il a déclaré que leur garantie était définie à une température nettement plus élevée que la norme de l'industrie. Quelqu'un a demandé "et alors". L'orateur a déclaré que plusieurs produits de fabricants auraient une durée de vie de réécriture nettement inférieure à celle de leurs pièces aux mêmes températures qu'avant. Mon souvenir était 5x deviendrait <1x. Il a dit que c'était très non linéaire. J'ai compris que la programmation à 80 ° C au lieu de 25 ° C serait une "mauvaise chose".

Ainsi, la réécriture flash combinée à une puce très chaude, pourrait également la rendre inutile en moins de 10 secondes.

Edit:
Je pense que "libérer la fumée bleue de la mort" est une contrainte plus difficile que nécessaire. Si l'un des éléments suivants: le circuit de broche RESET, le détecteur de brunissement, les circuits de mise sous tension, l'oscillateur RC ou à cristal (et probablement quelques autres circuits) pouvaient être endommagés, la puce serait rendue inutile.

Comme d'autres l'ont noté, briser le flash le tuerait également de manière irréparable.

"Smoke" semble impressionnant, mais les attaques mortelles moins évidentes sont toujours fatales et beaucoup plus difficiles à détecter.

Une source potentielle de cette destruction est le verrouillage SCR, où des transistors involontaires (intrinsèques) dans une puce se réunissent pour former une sorte de TRIAC qui peut alors absorber beaucoup de courant. Cela peut facilement faire sauter des fils de liaison, et j'ai même vu des appareils en plastique visiblement déformés à cause de la chaleur produite.

La cause typique est de conduire (même momentanément) une entrée au-dessus ou au-dessous des rails d'alimentation ou de masse respectivement, mais je suppose que vous pourriez voir cela se produire si une entrée était laissée flottante. Et il n'est alors pas difficile d'imaginer un circuit où le flottement de l'entrée était contrôlé par logiciel (bien que ce soit une chose très stupide à autoriser).

Il est POSSIBLE qu'un logiciel écrit intentionnellement à cet effet, destiné à un processeur très spécifique, puisse être en mesure de forcer l'overclocking au point où le processeur surchaufferait. A condition, bien entendu, que le processeur contienne des registres de contrôle d'horloge configurables par logiciel.

Il n'est PAS possible que TOUS les processeurs soient endommagés de cette façon, bien sûr. Si cela était vrai, il y aurait eu des milliards de Z80 et 6800 et 6502 mis à l'écart par des tyros capricieux d'écriture de logiciels alors que nous tapions toujours le code machine manuellement, faisant beaucoup d'erreurs aléatoires.

Ceci est mon entrée pour ruiner un microcontrôleur avec le moins de pièces possible ...

Basculez simplement les broches de sortie à quelques kHz!

Cependant, vous ne pouvez toujours pas voir de fumée, selon le mode de défaillance interne.

^{simuler ce circuit - Schéma créé à l'aide de CircuitLab}

--Modifier, ajouté le 22 août--

Maintenant, je ne pense pas que vous puissiez ruiner un microcontrôleur avec les critères donnés. Mais vous pouvez FACILEMENT ruiner les circuits externes avec le mauvais code. Un exemple qui me vient à l'esprit est un simple convertisseur boost que j'ai conçu récemment ... une simple pause du code pendant le débogage pourrait court-circuiter une inductance à la terre via un MOSFET. POOF

En termes de code de mode utilisateur normal, je ne pense pas que vous puissiez écrire quoi que ce soit qui puisse casser la puce.

Cependant, je me souviens de l'époque des microprocesseurs qui pouvaient être détruits en moins d'une minute voire de quelques secondes si le dissipateur thermique tombait. Ils ont ensuite ajouté des circuits de détection thermique qui ralentiraient l'horloge si la pièce devenait trop chaude. Maintenant que nous sommes en mesure de mettre en place beaucoup plus de transistors que ce qui peut être utilisé à la fois, les puces sont capables de produire plus de chaleur que le dissipateur thermique ne peut dissiper et sa gestion de l'alimentation et les circuits thermiques qui assurent sa sécurité. Par exemple, voir Intel Turbo Boost 2.0. Par conséquent, il semble tout à fait possible de faire fondre une puce si vous êtes en mesure de contourner ou d'augmenter la limite de la gestion de l'alimentation et du circuit thermique. Donc, si ceux-ci sont sous contrôle logiciel (aucune idée; cela nécessite peut-être une mise à jour du BIOS?), Alors vous pouvez exécuter un tas de boucles parallèles, ainsi que le travail GPU intégré, ainsi que le décodage et l'encodage H.264 matériel, et tout ce que la puce peut faire, tout à la fois jusqu'à ce que la puce surchauffe et émette la fumée bleue magique.

Je connais le mieux les processeurs STM32, donc ceux-ci s'appliquent le plus à cette famille. Mais des approches similaires peuvent également être possibles avec d'autres processeurs:

1. Il existe un mode de protection en écriture permanent. Donc, si vous programmez ce bit et un programme inutile sur le FLASH, le MCU ne pourra plus jamais être utilisé. Je ne sais pas si cela compte comme «brique», mais cela implique un mécanisme matériel permanent.

2. Les broches de programmation sont reconfigurables en GPIO. Parce que la broche d'horloge est entraînée par le dispositif de programmation, cela pourrait être utilisé pour provoquer un court-circuit. Très probablement, cela briserait cette seule broche, ce qui étant une broche de programmation serait assez mauvais.

3. Comme mentionné par dirkt, les PLL peuvent être utilisées pour overclocker le processeur. Cela pourrait éventuellement provoquer une surchauffe ou l'endommager.

Qui a dit que cela ne comprenait pas à quel point le processus de conception impliquait de telles puces. Cela ne signifie pas que les erreurs ne se produisent pas et que la couverture du code des régressions et des cas d'angle manque parfois des choses, mais déclarer que TOUS ou même la plupart des processeurs ont ce défaut est logiquement douteux.

Demandez-vous simplement ce qui se passe lorsqu'un overclockeur dépasse les exigences de synchronisation (en supposant qu'il ne surchauffe pas). la puce échoue et corrompt peut-être la mémoire et même l'accès au disque dur, mais fondamentalement, le processeur se relancera et exécutera à nouveau le système d'exploitation si la corruption est corrigée. Quel type de microcode correctement conçu pourrait donc causer PLUS de perturbations que ce scénario? - réponse très probablement aucune.

TLDR; Tous les processeurs ont ce défaut - PAS

Je crois qu'il est certainement possible de détruire physiquement un micro-contrôleur (MC) avec un logiciel. Tout ce qui est requis, c'est la combinaison du MC pour exécuter une boucle "serrée" d'instructions qui provoque une utilisation à 100%, et un dissipateur de chaleur "défectueux" qui permet à la chaleur à l'intérieur de la puce de s'accumuler. Que la panne prenne des secondes, des minutes ou des heures, cela dépendra de la vitesse à laquelle la chaleur s'accumule.

J'ai un ordinateur portable que je ne peux utiliser que 50% d'utilisation continue. Si je dépasse cela, l'ordinateur s'arrête. Cela signifie qu'à 50% d'utilisation, la température MC est inférieure au point de déclenchement défini. À mesure que l'utilisation augmente, la température du MC augmente jusqu'à ce que le point de déclenchement soit atteint. Si le circuit d'arrêt thermique ne fonctionnait pas (ou n'en avait pas), la température du MC continuerait d'augmenter jusqu'à ce qu'il soit détruit.

^{simuler ce circuit - Schéma créé à l'aide de CircuitLab}

#include <avr/io.h>

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

Le code ci-dessus amène le MCU à pousser PB2 haut tout en tirant PB4 bas, ce qui crée un court-circuit de VDD à PB2 à PB4 à GND et rapidement les pilotes de port de PB2 et / ou PB4 vont frire. Le court-circuit peut être une erreur innocente comme un pont de soudure accidentel.