uC Aufhängung technisch möglich?

[Martin (Gast)]

Aus gegebenem Anlass: Können sich Mikrocontroller aufhängen?
Damit ist nicht der Fehlerfall gemeint, wenn eine schlechte Software 
aufgespielt ist und der Code in einer Dauerschleife ausgeführt wird.

[Christian S. (roehrenvorheizer)]

Ja klar, so wie jede Art von Maschine, wenn sie von außen mit einer 
hinreichenden Störung beaufschlagt wird.

MfG

[Gerhard O. (gerhard_)]

Martin schrieb:
> Aus gegebenem Anlass: Können sich Mikrocontroller aufhängen?
> Damit ist nicht der Fehlerfall gemeint, wenn eine schlechte Software
> aufgespielt ist und der Code in einer Dauerschleife ausgeführt wird.

Hardwaretechnisch, wahrscheinlich ja. Mögliche Ursachen:

- Verseuchte Versorgungsspannung mit ungenügenden Stütz Cs,
- Unzuverläßige, schwankende Vcc
- Schlechte RESET Beschaltung
- Brownouts ohne aktivierten Supervisor
- Ungenügende Betriebsspannung, bei beschreibung von FLASH Probleme
- Kosmische Strahlungspartikel die den PC oder Stack oder sonstige 
kritische Speicherzellen verändern bzw. korruptieren
- Übertemperatur bei schneller Taktung
- Sonstige unbekannte Gründe:-)

[Christian S. (roehrenvorheizer)]

" Sonstige unbekannte Gründe:-)"

Siehe UFO.

Mfg

[Ben B. (Firma: Funkenflug Industries) (stromkraft)]

Einfach zu beantworten: Wenn man ihn ausreichend weit übertaktet, stürzt 
er garantiert ab - also definitiv ja.

Absturz heißt ja auch nichts weiter, daß der µC nicht mehr das macht, 
was er soll. Also er kann in eine Endlosschleife geraten oder es gibt 
einen ungewünschten Reset.

Was mich mal im Zusammenhang interessiert, speziell zu den AVRs: Was 
machen die bei einem fehlerhaften Maschinencode? Eine x86 CPU meldet 
sich mit einem "Illegal Opcode", aber so einen Interrupt hat der AVR 
nicht...

[A. S. (Gast)]

Ben B. schrieb:
> : Was machen die bei einem fehlerhaften Maschinencode?

Gibt's den denn? Illegalen opcode muss man sich ja auch leisten 
können...

[spess53 (Gast)]

Hi

>Gibt's den denn? Illegalen opcode muss man sich ja auch leisten
>können...

Es gibt einige Befehle im AVR-Befehlsssatz die nur für die XMegas gelten 
(z.B. XCG, LAS, LAC, LAT ...). Allerdings hab ich nie ausprobiert, was 
die in einem AVR-Programm veranstalten.

MfG Spess

[georg (Gast)]

Martin schrieb:
> Können sich Mikrocontroller aufhängen?

Höchstens aus Verzweiflung über die schlechte Software.

Martin schrieb:
> und der Code in einer Dauerschleife ausgeführt wird.

Irgendwo im Speicherraum gibt es immer eine Endlosschleife, egal aus 
welchem Grund der Prozessor nicht mehr das tut was der Programierer 
gemeint hat.

Georg

[Andi (Gast)]

> uC Aufhängung technisch möglich?

Natürlich ist das technisch möglich, du brauchst halt einen Faden oder 
ein Stück Schnur. Macht sich sicher gut als nerdigen Weihnachtsschmuck.

[Ben B. (Firma: Funkenflug Industries) (stromkraft)]

Na wenn man z.B. mit dem Stack Mist baut, schickt man beim RET jede CPU 
ins Nirvana. Wenn die dann probiert, irgendwelche Daten wie Texte 
auszuführen, werden das bestimmt nicht alles gültige 
Maschinenbefehle/Opcodes sein. Gibts dann direkt einen Reset wenn der 
auf so einen ungültigen Befehl aufläuft?

Das Problem bei µC-Abstürzen ist eher, wenn durch ungünstige 
Konstellationen Änderungen an der Hardware-Konfiguration passieren. Dann 
kann das Ding auch mal recht schnell abrauchen oder wenn keine 
Sicherungsmaßnahmen greifen dreht irgendein Motor genüßlich über seinen 
Endpunkt hinaus und zermatscht wenn man Pech hat noch irgendwas am 
Aufbau.

[I don‘t like Mondays (Gast)]

Es ist Freitag!

[Dirk B. (Gast)]

Ben B. schrieb:
> Was mich mal im Zusammenhang interessiert, speziell zu den AVRs: Was
> machen die bei einem fehlerhaften Maschinencode?
lt. Forschungsbericht aus einem anderen Thread bei µC-net am 
verbreiteten Beispiel $ffff wird UOP wie NOP ausgeführt d.h. die warten 
1 Takt mit Nichtoperation und machen danach unauffällig weiter. Spannend 
wird das wenn die µC nicht zu ende programmiert wurden und praktisch 
einen Teil des Flash als UOP/NOP-Slide belassen haben der ... (???) 
evtl. zum Anfang führt. Bei geringer Speicherausnutzung könnte ein 
zufälliger Sprung dadurch überwahrscheinlich wie ein Reset wirken 
(allerdings ohne Initialisierung worauf Resetroutinen häufig nicht 
vorbereitet sind). Kurz: interessante Fehlermöglichkeit.

Bei über 100 'offiziellen' dokumentierten 'NOP' Opcodes mit 1,2 oder 
durchschnittlich 1,5 Taktdauern sind die UOP mit vermutlich genau einem 
Takt aber eher syntaktischer Zucker.

[fop (Gast)]

Vor wenigen Jahren wurde erst komplett geklärt, was ein MOS6510 treibt, 
wenn man ihn ein 0x02 ausführen lässt.
Bis man sowas vom AVR erfährt kann also noch dauern.

[M. K. (sylaina)]

spess53 schrieb:
> Es gibt einige Befehle im AVR-Befehlsssatz die nur für die XMegas gelten
> (z.B. XCG, LAS, LAC, LAT ...). Allerdings hab ich nie ausprobiert, was
> die in einem AVR-Programm veranstalten.

Also bei mir meldet der AVR-GCC (hier in Version 4.8.1) einen illegalen 
OpCode für die MCU (Fehler wird geworfen) ;)

[Ben B. (Firma: Funkenflug Industries) (stromkraft)]

> MOS6510 treibt, wenn man ihn ein 0x02 ausführen lässt.
HCF

Wenn 0xFFFF als NOP ausgeführt wird, läuft halt irgendwann der 
Befehlszeiger über, der landet dann wieder bei Null und das erzeugt 
einen Reset.

[Andreas B. (bitverdreher)]

fop schrieb:
> Vor wenigen Jahren wurde erst komplett geklärt, was ein MOS6510 treibt,
> wenn man ihn ein 0x02 ausführen lässt.

Erzähl mal. Das interessiert mich wirklich. Beim 6502 gab es da einige 
sehr interessante undokumentierte Befehle.

[Rolf M. (rmagnus)]

M. K. schrieb:
> spess53 schrieb:
>> Es gibt einige Befehle im AVR-Befehlsssatz die nur für die XMegas gelten
>> (z.B. XCG, LAS, LAC, LAT ...). Allerdings hab ich nie ausprobiert, was
>> die in einem AVR-Programm veranstalten.
>
> Also bei mir meldet der AVR-GCC (hier in Version 4.8.1) einen illegalen
> OpCode für die MCU

Zur Laufzeit? Es geht hier nicht darum, was der Compiler macht, sondern 
darum, was der Prozessor macht.

> (Fehler wird geworfen) ;)

Wohin?

[Stefan F. (Gast)]

Ben B. schrieb:
> Wenn 0xFFFF als NOP ausgeführt wird, läuft halt irgendwann der
> Befehlszeiger über, der landet dann wieder bei Null und das erzeugt
> einen Reset.

Nein, das erzeugt einen neustart des Programms.

Ein Reset (Zurücksetzten der Hardware und Register) ist etwas anderes.

[Peter D. (peda)]

Martin schrieb:
> Können sich Mikrocontroller aufhängen?

Die ersten AVRs hatten da äußerst schwerwiegende Fehler bei Power-On.
Das Reset war/ist nur ein einfaches Zeitglied. Wenn die VCC zu langsam 
steigt oder schwankt, erfolgt kein ordentliches Reset und der 
Programmcounter startet irgendwo im Flash. Auch der EEPROM kann dann 
versehentlich Schreibzyklen starten, d.h. seinen Inhalt vergessen.

Die späteren AVRs haben ein Brownoutreset, was man für zuverlässiges 
Arbeiten immer enablen muß. Leider schluckt das sehr viel Strom (~30µA), 
was ungünstig für Batteriebetrieb ist. Dann muß man einen sparsameren 
externen Reset-IC anschalten.

Es gab/gibt aber noch weitere MCs, wo beim Power-On-Reset geschlampt 
wurde.

[Stefan F. (Gast)]

Bei Batteriebetrieb hat man dieses Reset Problem allerdings eher selten. 
Ich aktiviere den Brown-Out Detektor nur bei Betrieb an Netzteilen.

[Jacko (Gast)]

MÖGLICH ist alles, was nicht unmöglich ist...

Haben wir ein FEHLERFREIES Programm, kann es software-mäßig
kein Aufhängen geben.

Kleine Abschweifung:
Allerdings gibt es schon Gerichtsurteile, die den Käuferwunsch nach
FEHLERFREIER Software, oder auch nur den gratis-Nachbesserungswunsch
des Kunden als Käufer-Traumtänzerei verworfen haben...

Kaufst du dir dann mal ein selbstfahrendes Kraftfahrzeug - und die
Software wird wegen böser Mängel ein paar Monate später verboten,
hast du also auch kein Nachbesserungsrecht. Und die Hardware-Nach-
rüstung (Pedale und Lenkrad) wird ein Verkehrsminister der bekannten
Art auch von Produzenten gewollt fehlerhafter Software fernhalten...
 Kommt uns das bekannt vor?

Hardwaremäßig kann es schon Effekte durch schlechte EMV geben,
die (wie schon in anderen Antworten) den Programmzähler in
ungewollte Bereiche (Daten...) führen, wo sich nach Murphy's Law
haufenweise Endlosschleifen finden lassen.

Woher weißt du, das der Programm-Code FEHLERFREI ist?
Und wenn ja:
Suchst du eine Fehlerursache, oder eine Entschuldigung?

Im ersten Fall lässt sich durch EMV-Optimierung noch das eine,
oder andere erreichen.

[Stefan F. (Gast)]

Jacko schrieb:
> Kaufst du dir dann mal ein selbstfahrendes Kraftfahrzeug
> ... kein Nachbesserungsrecht.

Ein interessanter Aspekt, damit hast du mich zum Nachdenken angeregt.

[Aufgemerkt (Gast)]

Andi schrieb:
> Natürlich ist das technisch möglich, du brauchst halt einen Faden oder
> ein Stück Schnur. Macht sich sicher gut als nerdigen Weihnachtsschmuck.

Nein,
der TO hat ausdrücklich betont: "sich aufhängen".
Das was du beschreibst ist "aufgehängt werden".

Der µC müsste also so etwas wie KI, eigene Energie und eigene 
mechanische Fähigkeiten für den Aufhängeprozess aufweisen, um sich 
selbst aufzuhängen.

Hieran wird natürlich bereits intensiv geforscht und ich bin mir sicher, 
dass innerhalb der nächsten 2 Jahrzehnte sichselbstaufhänge µC's 
verfügbar sind.

[Rudolph R. (rudolph)]

Aufgemerkt schrieb:
> Hieran wird natürlich bereits intensiv geforscht und ich bin mir sicher,
> dass innerhalb der nächsten 2 Jahrzehnte sichselbstaufhänge µC's
> verfügbar sind.

Die Elektor hat vor 20+ Jahren mal in einer Ausgabe der xxx Schaltungen 
einen JFS Pin beschrieben.

[Karl B. (gustav)]

Martin schrieb:
> Aus gegebenem Anlass: Können sich Mikrocontroller aufhängen?

Ja,
für den Fall, dass Interrupts sich gegenseitig ins Gehege kommen.
Gerade bei Interrupts, die auf äußere Ereignisse reagieren, wie INTO,
die gerade dann kommen, wenn der UART mit Interrupt dazwischenfunkt.
Und noch ein, zwei Timer-Interrupts.usw.

ciao
gustav

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

Peter D. schrieb:
> Die ersten AVRs hatten da äußerst schwerwiegende Fehler bei Power-On.

Das musste ich auch gerade bei einem STM8S103 erfahren (Bicolor 
Filmleuchte). Steigt VCC zu langsam, kommt er über ein paar Anfangzeilen 
anscheinend nicht hinaus. Eine LED am MC blinkte zwar, aber sonst tat 
sich nichts.
Bei längerem Reset nach dem Starten oder Antippen von RST im Betrieb 
ging die Leuchte dann reproduzierbar in Betrieb.

[Berufsrevolutionär (Gast)]

Martin schrieb:
> Damit ist nicht der Fehlerfall gemeint, wenn eine schlechte Software
> aufgespielt ist

Auch gute Software kann in einen Deadlock laufen, nur ist sie eben gut 
darin diesen deadlock wieder aufzulösen bspw. durch WDT-IRQ.
Oder als externe HW-Lösung inkl Brownout-detection die den prozessor 
wieder auf Anfang setzt.

https://de.wikipedia.org/wiki/Deadlock_(Informatik)

[Karl B. (gustav)]

Hi,
SRAM wird direkt nach dem Start so von zufälligen Inhalten gelöscht:
Aber (!)
Den Watchdog hatten wir noch vergessen.
Wird versucht, diesen innerhalb des Programms nochmals zu verändern, 
geht das meistens nicht.

Bei mir klappt's nämlich nicht, was im Tutorial steht:

https://www.mikrocontroller.net/articles/AVR-Tutorial:_Watchdog#WDT_durch_Software_aktivieren.2Fdeaktivieren

ciao
gustav

[Bernd W. (berndwiebus)]

Hallo Aufgemerkt.

Aufgemerkt schrieb:

> Hieran wird natürlich bereits intensiv geforscht und ich bin mir sicher,
> dass innerhalb der nächsten 2 Jahrzehnte sichselbstaufhänge µC's
> verfügbar sind.

Wenn die KI besser wird, wird sie menschenähnlicher und bekommt 
menschenähnliche Fehler. Also warum sollte eine hinreichend 
fortschrittliche KI nicht auch Depressionen bekommen?

Vermutlich würde sie dann aber trozdem eher durchbrennen, als sich 
aufzuhängen.

Mit freundlichem Gruß: Bernd Wiebus alias dl1eic
http://www.dl0dg.de

[Bernd W. (berndwiebus)]

Hallo Martin.

Martin schrieb:

> Aus gegebenem Anlass: Können sich Mikrocontroller aufhängen?
> Damit ist nicht der Fehlerfall gemeint, wenn eine schlechte Software
> aufgespielt ist und der Code in einer Dauerschleife ausgeführt wird.

D.h. aus Hardware Gründen. Und da gibt es eine Menge Möglichkeiten:

In EDN gab es 2016 einen Artikel dazu: "Latch-Up durch Power Cycle".

Siehe: https://www.edn.com/Pdf/ViewPdf?contentItemId=4441325

Als Gegenmaßnahme wird in der AN4563 von NXP allerdings auch ein 
Microcontroller empfohlen. Siehe: 
https://www.nxp.com/docs/en/application-note/AN4563.pdf

Mit freundlichem Gruß: Bernd Wiebus alias dl1eic
http://www.dl0dg.de

[sega (Gast)]

Aufgemerkt schrieb:
> Hieran wird natürlich bereits intensiv geforscht und ich bin mir sicher,
> dass innerhalb der nächsten 2 Jahrzehnte sichselbstaufhänge µC's
> verfügbar sind.

Noch etwas länger dürfte die Implementation des Absturzes dauern, der 
sich nur unmittelbar nach dem Aufhängen ereignen sollte. Ein 
Selbstheilungsfeature sozusagen.

[r. (Gast)]

Christian S. schrieb:
> " Sonstige unbekannte Gründe:-)"
>
> Siehe UFO.
>
> Mfg

Soll SUG heißen...

[Aufgemerkt (Gast)]

Bernd W. schrieb:
> Wenn die KI besser wird, wird sie menschenähnlicher und bekommt
> menschenähnliche Fehler. Also warum sollte eine hinreichend
> fortschrittliche KI nicht auch Depressionen bekommen?
>
> Vermutlich würde sie dann aber trozdem eher durchbrennen, als sich
> aufzuhängen.

Guter Aspekt.
Darum diskutieren wir hier so eifrig!

sega schrieb:
> Noch etwas länger dürfte die Implementation des Absturzes dauern, der
> sich nur unmittelbar nach dem Aufhängen ereignen sollte. Ein
> Selbstheilungsfeature sozusagen.

Und dann wird der Knackpunkt sein, wie man diese Rekursion stoppt!
Also die Technik in den nächsten Jahrhunderten bleibt spannend.

[fop (Gast)]

Andreas B. schrieb:
> Erzähl mal. Das interessiert mich wirklich. Beim 6502 gab es da einige
> sehr interessante undokumentierte Befehle.

Ich lass dann mal erzählen. War in diesem Vortrag :
https://media.ccc.de/v/27c3-4159-en-reverse_engineering_mos_6502

Wenn nicht, gibt es Emulatoren in Java auf Webseiten, wo man alle 
internen Pegel sehen kann.