MIC mit Software zerstören

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.