|
Anzeige
|
MIC mit Software zerstören
Gast
#4626354
Guten Tag und ein schönes Wochenende, folgende Frage, welche Möglichkeiten hätte ich per Software einen Mikrocontroller zu zerstören. Eine wäre ja unbenutzte Pins auf Ausgang und GND schalten und dann mit einem 1er Pegel belasten, dann würde er ja über kurz oder lange "abrauchen". Gibt es auch noch andere Möglichkeiten oder ist das die einzige per Software den MIC zu zerstören? Wäre super wenn Ihr mir helfen könntet. Mit freundlichen Grüßen Wozu willst du ihn Zerstören? Es reicht doch die Software unbrauchbar zu machen. Viele Mikrocontroller Können ihren Flash selbst beschreiben (Für Firmware Updates) Oder haben Eeprom Zellen. Tomus schrieb: > unbenutzte Pins auf Ausgang > und GND schalten Da wird hingegen bei vielen Mikrocontrollern nicht so viel kaputt gehen. Tomus schrieb: > Eine wäre ja unbenutzte Pins auf Ausgang > und GND schalten und dann mit einem 1er Pegel belasten, dann würde er ja > über kurz oder lange "abrauchen". Nein. Eine wahrscheinliche Möglichkeit: Die Spannung fällt ab, entweder weil deine Quelle schlapp macht oder der Chip intern überlastet ist. Dann gibts nen Reset. Und das wars mit abrauchen. SO hab ich zumindest noch keinen Microcontroller zerstört. Was hast du denn genau vor? Geht es hier im eine Art Produktschutz? Tomus schrieb: > folgende Frage, welche Möglichkeiten hätte ich per Software einen > Mikrocontroller zu zerstören. Kommt auf den µC an. Viele können sich selbst programmieren. Da liegt es nahe, das Flash zu löschen. Wenn es um das heilige Programm geht sollte das reichen. Bei manchen kann man die PLL der Takterzeugung mit falschen Werten abkochen. Warum sollte man einen µC per SW zerstören wollen? (Ich vermute ganz stark, dass hier eine Funktion zur Selbstzerstörung beabsichtigt ist.) Ich habe einen µC schon mal per Software zwar nicht zerstört, aber unbrauchbar gemacht indem ich ihn vor Auslesen/Wiederbeschreiben gesichert hatte. Damit war dann auch die JTAG Schnittstelle deaktiviert und ich konnte das nicht mehr mit einem "MassErase" zurücksetzen - Chip musste ich auslöten und wegwerfen. Das war zum Test ob/wie die Sicherungen vom STM32 funktionieren. Tomus schrieb: > dann würde er ja über kurz oder lange "abrauchen". Oder auch nicht. Eher nicht. Wenn überhaupt, dann dieser eine Pin. Ein Prozessor mit XCS eXplode on Carry Set ist mir nicht bekannt. (Beim MSP430 sagt man, wenn man mit langsamer Taktfrequenz das Flashmillionenmal überschreibt, hätte man es ruiniert). Und STM32 haben permanet write protect. Bei zu schlecht gekühlten alten Pentiums (ohne trotteling) konnte man durch übermässigen Befehlsgebrauch den Prozessor bis zur zerstörung überhitzen. > trotteling
Tja damals war das Stromsparen noch keinem Trottel wichtig.
Wenn ich sowas bauen müßte, dann mit einer entsprechend starken hohen
Spannung (z.B. 24 oder 48V) und einem dicken Thyristor zu +Vcc 3V3/5V,
der "bei Bedarf" vom Controller gezündet werden kann. Das haut
garantiert die Scheiße aus dem Controller und erzeugt einen sehr
effektvollen Abgang bis irgendeine Sicherung (notfalls der Trafo) kommt.
Michael B. schrieb: > Bei zu schlecht gekühlten alten Pentiums (ohne trotteling) Das ging auch schon auf den Pentiums mit Trotteling. Denn ob der richtig oder falsch dividiert ist thermisch egal. Michael B. schrieb: > Bei zu schlecht gekühlten alten Pentiums (ohne trotteling) konnte man > durch übermässigen Befehlsgebrauch den Prozessor bis zur zerstörung > überhitzen. In der Ära der Kernspeicher konnte man Rinkerne mit einem jmp $ abrauchen lassen. Offtopic: wieso muss man denn jetzt solche Threads mit eindeutigem Bezug zu Controller und Elektronik ins Offtopic verschieben (und damit den TO aus seinem eigenen Thread aussperren)? Somit kommt garantiert kein Feedback mehr vom TO. Was soll das immer? Tja, in diesem Forum nennt man das Moderation. Antwort schreiben |
Anzeige
|
