Forum: Mikrocontroller und Digitale Elektronik Mikrocontroller Fehler "provozieren" + workarounds


von Thomas (Gast)


Lesenswert?

Hallo allerseits

Ich bin gerade dabei, einen Mikrocontroller (ATmega2560) im Rahmen eines 
Universitätsprojektes auf verschiedene Fehler hin zu untersuchen und wie 
man diese softwaremäßig (z.B. mithilfe eins watchdogs) minimieren 
kann...
(Es geht um AVR-Mikrocontroller, die in einem mechanischen Systemen 
eingesetzt werden sollen, das sehr zuverlässig funktionieren soll, da es 
kritischen Umgeungen eingesetzt wird.)
Z.Zt. habe ich hauptsächlich einige analoge Servos und mehrere Joysticks 
an den Microcontroller angeschlossen...  Besonders Sicherheitskritisch 
sind hierbei die Signale zu den Servos.

 Da sicherlich auch die Community hier davon profitieren würde, lade ich 
zum mitmachen ein...

Ich wäre besonders froh über Vorschläge, und Erfahrungen, was schonmal 
"schiefgelaufen" ist (auch simple Sachen, wie Stecker falschrum 
einstecken, GND mit VCC verbinden, oder sonstige Kurzschlüsse 
ausgelöst.)
Hat schonmal jemand Erfahrungen mit EMV gesammelt? (z.b. daß die PWM 
Signale zu den Servos irgendwie verändert wurden)
Vielleicht kann ich auch Tests machen, die ihr euch nicht zurtraut, weil 
ihr euren Mikrocontroller damit beschädigen würdet etc etc....

Ich werde meinerseits dann versuchen, möglichst viele Ergebnisse hier zu 
posten...

Grüße, Thomas

von Peter D. (peda)


Lesenswert?

Thomas wrote:
> Ich bin gerade dabei, einen Mikrocontroller (ATmega2560) im Rahmen eines
> Universitätsprojektes auf verschiedene Fehler hin zu untersuchen und wie
> man diese softwaremäßig (z.B. mithilfe eins watchdogs) minimieren
> kann...

Es ist ein weit verbreiteter Irtumm, daß ein Watchdog ein Gerät 
zuverlässiger mache, das ganze Gegenteil ist der Fall.

Insbesondere, wenn der Watchdog schon zu Beginn der Entwicklung 
verwendet wird, macht er das System extrem unzuverlässig, da er 
sämtliche Fehler im Softwareablauf oder EMV kaschiert.

Wenn es aber darum geht, Fehler in der externen Hardware zu erkennen, 
z.B. ob der Motorstrom über eine bestimmte Zeit hinaus zu hoch ist 
(Überlast), dann macht man diese Überwachungsprozesse mit den ganz 
normalen Timern direkt im Programm in Kombination mit AD-Wandlern.
Die Zuverlässigkeit wird dadurch zwar nicht gesteigert, aber 
Folgeschäden (z.B. durchgebrannte Motoren) können verhindert werden.
Und es können Diagnosemeldungen ausgegeben werden.


Wenn überhaupt ein Systemwatchdog verwendet werden soll, dann darf er 
erst ganz zum Schluß hinzugefügt werden, nachdem alle Funktionen 
einwandfrei laufen.

Ist eine Funktionserweiterung zu entwickeln, muß der Watchdog natürlich 
zuerst deaktiviert werden, damit man die dabei gemachten Fehler wieder 
erkennen kann.


Peter

von Εrnst B. (ernst)


Lesenswert?

Da hat Peter durchaus recht, ähnlich ist es z.B. mit "asserts" in 
C-Code. Die macht man für die Release-Version am besten auch nicht raus, 
obwohl das vielerorts so praktiziert wird...
Währe wie ein Autohersteller, der die Airbags wieder ausbaut, weil "die 
ja auf der Testfahrt auf dem Firmengelände auch nicht gebraucht 
wurden"...

Beim Watchdog wäre evtl folgendes Sinnvoll:
Nach dem Reset MCUCR prüfen, wenn vom Watchdog ausgelöst:

Alle Ausgänge in "sicheren" Zustand bringen, und danach in 
Endlosschleife gehen, Warnled blinken lassen.
So sieht der Endanwender wenigstens, dass mit seinem Gerät was nicht in 
Ordnung ist, und er ihm besser nicht mehr 100%ig vertrauen sollte.

von Andreas K. (a-k)


Lesenswert?

Das hängt ein bischen davon ab, wozu das entwickelte Teil gut ist. Wenn 
beim Ausfall einer Steuerung im Winter die Wasserrohre einfrieren, weil 
das Modul zwecks Warnung des nicht anwesenden Entwicklers fröhlich 
streikend vor sich hinblinkt, dann ist damit niemandem gedient.

Dass Watchdogs Fehler verdecken können stimmt. Aber das ist auch ein 
bischen der Sinn der Sache. Denn die Vorstellung, dass man in einem 
nicht trivialen Controllersystem innerhalb der Entwicklungsphase 
wirklich alle Fehler findet, ist etwas gewagt.

Und dann wären da noch jene Fehler, die man schlecht kontrollieren kann. 
Hardwarefehler, Stromunterbrechungen, strunzdämliche Bedienung, ...

Also: Auf das Problem hinweisen ist richtig. Deshalb gleich den Betrieb 
einzustellen oft nicht.

von Carsten (Gast)


Lesenswert?

ACK @  Ernst Bachmann

"asserts" -> in VB "On Error Goto Next"

für die Basic MitBürger

Gruß Fred

von Winne Z. (rugbywinne)


Lesenswert?

Um ein paar "EMV"-Erfahrungen zu sammeln kannst Du mit einem 
Piezo-Gasanzünder Hochspannung in Deine Schaltung einkoppeln.

Oder nehme ein Relais ohne Entstörschaltung und schalte den Öffner der 
Relais in seine Zuleitung. Dann hast du einen einfachen Störgenerator.

1.Grundsätzliche EMV-Bedingungen einhalten. z.B. Geschirmtes Gehäuse
2.Einkoppelung in die Versorgungsleitungen
3.Einkoppelungen in die I/O-Leitungen die aus dem Gerät herausführen.

Geht was bleibend kaputt >> Hardwareschutz verbessern. 
>>>Schutzdioden/Schutzkondensatoren/Varistoren

fällt die Software/Hardware nur während der Störung aus >> Auch 
Hardwareschutz verbessern. Störungen "wegfiltern"

"Hängt" sich die Software bleibend auf >> Dann kommt der Watchdog oder 
Systemreset.

In EMV-Laboren gibt es dafür spezielle Geräte die das qualitativ und 
quantitativ besser können. Wenn Du kein Zugang zu einem EMV-Labor hast 
musst Du die Störungen selber erzeugen.

von Simon K. (simon) Benutzerseite


Lesenswert?

Carsten wrote:
> ACK @  Ernst Bachmann
>
> "asserts" -> in VB "On Error Goto Next"
>
> für die Basic MitBürger
>
> Gruß Fred

Naja. Nicht wirklich.
http://de.wikipedia.org/wiki/Assert

von Carsten (Gast)


Lesenswert?

ok ok  Simon K.

>Durch die Formulierung einer Zusicherung bringt der Entwickler eines >Programms 
seine Überzeugung über bestimmte Bedingungen während der Laufzeit >eines Programms 
zum Ausdruck und lässt sie Teil des Programms werden. Er >trennt diese 
Überzeugungen von den normalen Laufzeitumständen ab und nimmt >diese Bedingungen 
als stets wahr an. Abweichungen hiervon werden nicht >regulär behandelt, damit die 
Vielzahl möglicher Fälle nicht die Lösung des >Problems vereitelt, denn natürlich 
kann es während der Laufzeit eines >Programms dazu kommen, dass 2+2=4 einmal nicht 
gilt, z.B. weil Variablen >durch Programmfehler im Betriebssystem überschrieben 
wurden.

>Damit unterscheiden sich Zusicherungen von der klassischen Fehlerkontrolle >durch 
Kontrollstrukturen oder Ausnahmen (Exceptions), die einen Fehlerfall >als 
mögliches Ergebnis einschließen. In einigen Programmiersprachen wurden 
>Zusicherungen auf Sprachebene eingebaut, häufig werden sie als Sonderform >der 
Ausnahmen verwirklicht.


On Error Goto <Marke>

Carsten

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.