www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Bit im PC-Arbeitsspeicher beim Programmieren gekippt?


Autor: Sandy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Folgendes war passiert:
Mehrere Mikrocontroller wurden in baugleichen Steuerungen nacheinander 
programmiert. Beim Verify der programmierten Mikrocontroller wurde kein 
Fehler angezeigt. 25% der Steuerungen arbeiteten anschließend 
einwandfrei, die anderen Steuerungen hatten offensichtlich einen kleinen 
identischen Rechenfehler im Programm, für den ein gekipptes Bit in der 
Software ausreichen würde. Nach erneuter Programmierung arbeiteten alle 
Steuerungen wieder einwandfrei.

Für diesen Effekt habe ich keine eindeutige Erklärung. Kann es sein, daß 
im PC-Arbeitsspeicher beim Programmieren ein Bit gekippt war, so dass 
alle nachfolgend programmierte Steuerungen den Rechenfehler hatten?
Habt Ihr auch schon einmal so etwas erlebt?

Autor: Maik Werner (werner01)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vieleicht war ja genau da irgendwie EMP eventuell außerirdische oder ein
kleiner Quasar??

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hast du die Controller mit dem "gekippten" Bit ausgelesen oder woher 
weist du dass überall das gleiche Bit "gekippt" ist?

Nein sowas habe ich noch nie erlebt.

Autor: Sandy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Hast du die Controller mit dem "gekippten" Bit ausgelesen

leider nein

> woher weist du dass überall das gleiche Bit "gekippt" ist

das ist eine Vermutung, da sich alle Steuerungen bei einer Berechnung um 
den offensichtlich gleichen Betrag verrechneten

Autor: Verschöwrer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich würde auf die Illuminaten tippen - oder die Freimaurer!!

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>25% der Steuerungen arbeiteten anschließend
>einwandfrei, die anderen Steuerungen hatten offensichtlich einen kleinen
>identischen Rechenfehler im Programm, für den ein gekipptes Bit in der
>Software ausreichen würde.

Ich würde sagen das bei den ersten 25% ein Bit so gekippt ist,
das die offensichtlich falsche Berechnung korrigiert wird.

Autor: Martin Vogel (oldmax)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi
>das ist eine Vermutung, da sich alle Steuerungen bei einer Berechnung um
>den offensichtlich gleichen Betrag verrechneten
Nun, wenn alle das gleiche Programm abarbeiten, dann rechnen auch alle 
gleich falsch. Oder hab ich da was mißverstanden...
So wie ich das lese, denke ich, ein Programmfehler oder besser gesagt 
ein Programmierfehler.
Gruß oldmax

Autor: Christian H. (netzwanze) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich würde ja erstmal alle Prozessoren auslesen (falls Du nicht schon 
verfused hast) und vergleichen.

Oh - ich lese gerade, dass Du bereits alle forensisch verwertbaren 
Spuren vernichtet hast.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Beim Verify der programmierten Mikrocontroller wurde kein
> Fehler angezeigt.

Dann würde ich mal vom Naheliegensten ausgehen:
Ein Fehler im Programm, der sich durch Zufall auf 25% der Prozessoren 
nicht ausgewirkt hat. Zufall könnte zb sein, dass der eine Eingang ohne 
Pullup-Widerstand zufällig sich aus der Radiostrahlung die notwendige 0 
gesaugt hat, während alle anderen zufällig an diesem Pin just im Moment 
des Auslesens eine 1 erhalten haben. Es könnte aber auch ganz banal eine 
nicht initialisierte Variable sein :-)

Das heisst jetzt nicht, das das so war. Aber es wäre ein mögliches 
Szenario. Und es ist als Szenario sehr viel wahrscheinlicher als ein 
kosmisches Teilchen, welches sich ausgerechnet dieses eine Bit im PC 
gesucht hat um es umzustellen und dann auch noch ein Bit erwischt hat, 
welches im Programmfluss auf dem µC lediglich eine falsche Berechnung 
verursacht. Die Wahrscheinlichkeit dafür ist zwar nicht 0, aber 
wesentlich über ein paar tausendstel Prozent würde ich sie aus dem Bauch 
heraus nicht ansiedeln.

Dagegen ist die Wahrscheinlichkeit eines Software oder Hardware-Fehlers 
um ein paar Zehenerpotenzen größer und, wieder aus dem Bauch heraus, 
irgendwo bei 95%

Autor: Sandy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ein Fehler im Programm, der sich durch Zufall auf 25% der Prozessoren
> nicht ausgewirkt hat.

Nach erneutem Programmieren arbeiteten alle Mikrocontroller einwandfrei! 
Das schließt einen Programmfehler aus.

> Zufall könnte zb sein, dass der eine Eingang ohne
> Pullup-Widerstand zufällig sich aus der Radiostrahlung die notwendige 0
> gesaugt hat, während alle anderen zufällig an diesem Pin just im Moment
> des Auslesens eine 1 erhalten haben.

Auch das kann nicht erklärt werden, wenn nach erneutem Programmieren 
wieder alle in Ordnung war.

Autor: Christian H. (netzwanze) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn die Daten nach dem Programmieren auch verifiziert wurden, kann es 
sich ja nur nachher verändert haben.

Falls das Programm sich auf dem PC verändert hat, wieso funktionierte es 
denn beim nochmaligen Programmieren? Hast Du den Code am PC nochmal 
übersetzt? Wenn ja, hast Du den alten (angeblich defekten) Code 
überschrieben oder noch aufgehoben. Wenn letzteres, kannst Du die Codes 
ja mal vergleichen.

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sandy schrieb:
>> Ein Fehler im Programm, der sich durch Zufall auf 25% der Prozessoren
>> nicht ausgewirkt hat.
> Auch das kann nicht erklärt werden, wenn nach erneutem Programmieren
> wieder alle in Ordnung war.
Waren die Prozessoren vor dem erneuten Programmieren länger vom Strom 
getrennt/EEProm gelöscht, etc...

Wenn der Stack z.B. in der falschen Reihenfolge programmiert wird, dann 
funktioniert u.U. das Programm erst wieder nachdem es einmal neu 
gestartet wurde...

Wenn du sicher bist das alles bei dir i.O. ist (was du ja nun nicht mehr 
nachprüfen kannst bleibt ja nur folgendes:

- Illuminaten/Freimaurer!!
- EMP, Außerirdische, kleiner Quasar
- Verify/Programmer arbeiten inkorrekt

Autor: Christian H. (netzwanze) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Btw; ist in den Hex-Daten nicht eine Prüfsumme mit drin? Und überprüft 
der Programmer (welchen verwendest Du?) diese nicht beim Brennen?

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sandy schrieb:
>> Ein Fehler im Programm, der sich durch Zufall auf 25% der Prozessoren
>> nicht ausgewirkt hat.
>
> Nach erneutem Programmieren arbeiteten alle Mikrocontroller einwandfrei!
> Das schließt einen Programmfehler aus.

Nein, das tut es nicht.
Leider nicht.

alte Merkregel:
Durch Testen kann man immer nur das Vorhandensein eines Fehlers 
nachweisen. Niemals das Fehlen.

Wenn also ein Fehler von 'alleine verschwindet', ohne das eine 
nicht-esoterische Erklärung dafür gefunden werden kann, ist Feuer am 
Dach. Erfahrene Programmierer richten sich dann schon mal auf eine lange 
Nachtschicht ein, in der sie die uninitialisierte Variable, den 
Pointer-der-in-den-Wald-zeigt, den Array-Overflow der den Stack 
zerschossen hat etc. suchen gehen.
Du hast zwar in allen Prozessoren jeweils das identische Programm, wenn 
sich die Ergebnisse dann trotzdem unterscheiden kann nur noch die 2-te 
notwendige Komponente den Unterschied ausmachen: Die Daten, die in die 
Algorithmen hineingehen. Und hier kann der aus der Chaosthoerie bekannte 
'Schmetterlingseffekt' zum tragen kommen. Sind die Daten eben nicht 
identisch (zb weil ein ADC Wnadler involviert ist und die selbst auf ein 
und demselben Prozessor bei konstanter Eingangsspannung unterschiedliche 
Ergebnisse bringen), dann wirkt sich auf dem einen µC ein Programmfehler 
aus und auf dem anderen nicht.

(*) Ein Fehler der dadurch verschwindet, indem man das gleiche Programm 
ein 2-tes mal in den µC brennt, fällt zunächst unter eosterisch. 
Entweder ist der Brennprogramm korrekt gelaufen oder er ist es nicht. 
Ein Verify würde das aber zutage bringen. Da bei dir der Verify nicht 
angeschlagen hat, kann man sicherlich zunächst davon ausgehen, dass die 
Programmübertragung fehlerfrei war.

Autor: Sandy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Wenn die Daten nach dem Programmieren auch verifiziert wurden, kann es
> sich ja nur nachher verändert haben.

Mit was verifiziere ich? Es sind doch die Daten, die im 
PC-Arbeitsspeicher stehen, oder?

> Btw; ist in den Hex-Daten nicht eine Prüfsumme mit drin? Und überprüft
> der Programmer (welchen verwendest Du?) diese nicht beim Brennen?

Um nicht versehentlich die im Mikrocontroller abgelegten EEPROM-Daten zu 
ändern, wurde folgende Reihenfolge gewählt:

1) Alle Daten aus dem Mikrocontroller auslesen
2) Neu assemblieren
3) Mikrocontroller neu beschreiben

So ist auf einen Blick und in absoluten Stresssituationen 
sichergestellt, dass der Mikrocontroller sowohl das richtige Programm 
(sichtbar im Programmkopf) als auch seine alten EEPROM-Daten erhält.

Autor: Sandy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Durch Testen kann man immer nur das Vorhandensein eines Fehlers
> nachweisen. Niemals das Fehlen.

Es ist aber ein Fehler, der offensichtlich nicht im Programm zu suchen 
ist. Die Arbeitsumgebung blieb unverändert. Auch waren eine ganze Anzahl 
von Mikrocontrollern betroffen; es war kein Einzelfall.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sandy schrieb:
>> Durch Testen kann man immer nur das Vorhandensein eines Fehlers
>> nachweisen. Niemals das Fehlen.
>
> Es ist aber ein Fehler, der offensichtlich nicht im Programm zu suchen
> ist.

Für dich vielleicht.
Für mich ist der Fehler ziemlich offensichtlich im Programm zu suchen.

> Die Arbeitsumgebung blieb unverändert.

Inklusive zb. thermischen Rauschen, Handystrahlung und Radiowellen?
Also wenn ich bei meinem Mega einen Pullup vergesse, passieren die 
tollsten Dinge, je nachdem ob meine Freundin hinter mir ihre neuen 
Nylons spazieren trägt oder nicht :-)

> Auch waren eine ganze Anzahl
> von Mikrocontrollern betroffen; es war kein Einzelfall.

Umso schlimmer.
Und du hast bei allen gleich eine Neuprogrammierung gemacht, ohne erst 
mal bei einem auf Spurensuche zu gehen?

Na wenn du meinst.
Sagst du mir noch welche Firma das ist?

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Speicherfehler sind nicht grundsätzlich auszuschliessen, zumindest wenn 
ein normaler PC ohne ECC-Speicher verwendet wurde. Aber da alle Spuren 
vernichtet wurden lässt sich das nicht mehr nachweisen. Sollte 
allerdings der zum Programmieren verwendete PC in den nächsten Monaten 
eine gewisse Neigung zu Abstürzen haben, solche die man aus alter 
Gewohnheit gerne Microsoft in die Schuhe schiebt, dann könnte ein 
Zusammenhang bestehen.

Allerdings spricht die Wahrscheinlichkeit dafür, dass beispielsweise 
beim Programmieren versehentlich ein falsches Image/Hexfile verwendet 
wurde.

Autor: Sandy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Und du hast bei allen gleich eine Neuprogrammierung gemacht, ohne erst
> mal bei einem auf Spurensuche zu gehen?

Leider gab es Randbedingungen, die eine effektive Spurensuche 
verhinderten.

> Inklusive zb. thermischen Rauschen, Handystrahlung und Radiowellen?

Wie erzeugst Du damit in 75% aller unmittelbar benachbarter Steuerungen 
einen Rechenfehler und läßt die anderen 25% unbeeinflußt?
Wieso sollen diese Beeinflussungen nach Neuprogrammierung plötzlich 
keinen Einfluß mehr haben?

Autor: Christian H. (netzwanze) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sandy schrieb:
> Es ist aber ein Fehler, der offensichtlich nicht im Programm zu suchen
> ist. Die Arbeitsumgebung blieb unverändert. Auch waren eine ganze Anzahl
> von Mikrocontrollern betroffen; es war kein Einzelfall.
Was nochmal auf einen Fehler im Quellcode hindeutet. Ein gekipptes Bit 
im Controller kann sich ja nicht überall an der gleichen Stelle 
befinden.

Da Du aber die alten Daten (also das zuerst programmierte Binär- oder 
Hex-File) gelöscht oder überschrieben hast, und diese nicht mehr mit den 
aktuell verwendeten vergleichen kannst, ist es eh zu spät, den Fehler 
einzukreisen. Das einzige, was bleibt, ist der aktuelle Quellcode, den 
es auf eventuelle Programmierfehler (ja ich weiß, es gibt eine) 
abzusuchen ist.

Oder hast Du nur die "defekten" Prozessoren neu beschrieben und kommst 
noch an die (alten) Daten der anderen Prozessoren ran?

Ja => alte Prozessoren auslesen, neue Prozessoren auslesen und alle drei 
Binaries (alt, neu und auf dem pc) mittels binärem Diff vergleichen 
(alternativ reicht auch eine MD5- oder SHA-Prüfsumme, wobei man dabei 
die genaue Stelle des Unterschieds nicht finden kann).

Autor: Sandy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Allerdings spricht die Wahrscheinlichkeit dafür, dass beispielsweise
> beim Programmieren versehentlich ein falsches Image/Hexfile verwendet
> wurde.

Auch eine Verwechslung schweidet aus, da es genau 1 Programmfile gab.

Autor: Christian H. (netzwanze) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger schrieb:
> passieren die
> tollsten Dinge, je nachdem ob meine Freundin hinter mir ihre neuen
> Nylons spazieren trägt oder nicht :-)

Das ist aber doch unabhängig vom Prozessor oder ;-)

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian H. schrieb:

> Was nochmal auf einen Fehler im Quellcode hindeutet. Ein gekipptes Bit
> im Controller kann sich ja nicht überall an der gleichen Stelle
> befinden.

Je nachdem wie und womit programmiert wurde. Wenn das unabhängig 
Vorgänge sind, dann ist das mit Sicherheit auszuschliessen. Wenn das 
eine Serienfertigung mit entsprechender Programmiersoftware war, dann 
reicht ein einziger Fehler aus. Wobei das dann ggf. auch ein 
Übertragungsfehler gewesen sein kann.

Autor: Sandy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Christian H.

Leider wurden alle Spuren vernichtet (dafür aber das Projekt gerettet 
und den Kunden glücklich gemacht).

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sandy schrieb:
>> Und du hast bei allen gleich eine Neuprogrammierung gemacht, ohne erst
>> mal bei einem auf Spurensuche zu gehen?
>
> Leider gab es Randbedingungen, die eine effektive Spurensuche
> verhinderten.
>
>> Inklusive zb. thermischen Rauschen, Handystrahlung und Radiowellen?
>
> Wie erzeugst Du damit in 75% aller unmittelbar benachbarter Steuerungen
> einen Rechenfehler und läßt die anderen 25% unbeeinflußt?

Zum Beispiel in dem nicht alle Prozessoren zum auf die Nanosekunde exakt 
gleichen Zeitpunkt in Bezug auf die Phasenlage der Störsignale gestartet 
wurden!

Da gibt es elektromagnetische Wellen ohne Ende in der Luft!
Je nachdem ob der eine µC die Welle gerade in einem Nulldurchgang und 
ein anderer die Welle an ihrem Maximum erwischt, liest er vom Port was 
anderes ein!

Auch hast du erwähnt, dass die EEPROM Daten (per Design) bei jedem Proz 
erhalten blieben. Wer sagt dir, dass die alle identisch waren?

> Wieso sollen diese Beeinflussungen nach Neuprogrammierung plötzlich
> keinen Einfluß mehr haben?

Hat sie.
Aber so ist das nun mal mit Zufällen. Einmal treten sie auf ein anderes 
mal nicht.

Autor: Christian H. (netzwanze) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Wobei das dann ggf. auch ein
> Übertragungsfehler gewesen sein kann.
...der sich aber beim Verify gezeigt hätte.

> Speicherfehler sind nicht grundsätzlich auszuschliessen, zumindest wenn
> ein normaler PC ohne ECC-Speicher verwendet wurde.
Kommt drauf an, wie programmiert wurde.
Alles nacheinander; dann kommen die Dateien von der Platte.

Da wäre es gut zu wissen, ob nur die zuerst programmierten Prozessoren 
oder die Letzten fehleraft waren (Seriennummer?).

Sicherlich lässt sich aber auch das nicht mehr nachprüfen.

Aber es bringt ja sowieso nichts. Alle sachdienlichen Spuren sind 
vernichtet und der Programmierer besteht auf Korrektheit des Programms 
(obwohl kein Programm mit mehr als 0 Byte Größe fehlerfrei ist).

Autor: Sandy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Auch hast du erwähnt, dass die EEPROM Daten (per Design) bei jedem Proz
> erhalten blieben. Wer sagt dir, dass die alle identisch waren?

Waren sie nicht. Wir haben sie sogar munter geändert, um ggf. eine 
Abhängigkeit zu finden. Den Rechenfehler hat das aber nicht 
interessiert. Erst die Neuprogrammierung brachte den Erfolg.

Autor: Sandy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> dann kommen die Dateien von der Platte.

Beim Starten der Programmierumgebung wurde die Platte nur einmal 
gelesen. Danach kamen alle Daten aus dem PC-Arbeitsspeicher.

Autor: Steff (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aloah,

auch wenn es nicht ganz zum Thema passt...

Ich erinnere gern an eine Defekte/ falsch Programmierte South(North?) 
Bridge bei älteren PC's . Wurde damals eine Datei > 100 MB von Platte A 
nach Platte B kopiert waren die Daten geschreddert !

Wollte hier nur anmerken, auch auf den PC is nich immer verlass !!!

Ahoi

Steff

Autor: Andreas K. (derandi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sandy schrieb:
>> Auch hast du erwähnt, dass die EEPROM Daten (per Design) bei jedem Proz
>> erhalten blieben. Wer sagt dir, dass die alle identisch waren?
>
> Waren sie nicht. Wir haben sie sogar munter geändert, um ggf. eine
> Abhängigkeit zu finden. Den Rechenfehler hat das aber nicht
> interessiert. Erst die Neuprogrammierung brachte den Erfolg.


Ahja, ihr habt das Programm also geändert, der Fehler war aber immer 
noch da.
Aber nur ein anschließendes (erneutes) Programmieren mit dem 
original-Programm hat das Problem gelöst.
Warum hat das programmieren mit dem veränderten Programm also nicht 
geholfen?

Ahja, eins wär da noch: Selbst wenn da ein Bit im Arbeitsspeicher 
umgekippt ist, dann müssten die 25% mit korrekter Funktion vor den 
restlichen Programmiert worden sein.

Autor: Sandy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Warum hat das programmieren mit dem veränderten Programm also nicht
> geholfen?

Zum Verständnis: im EEPROM liegen Daten und nicht das Programm!
Es waren natürlich Mikrocontroller mit Flash-Speicher, in dem das 
Programm abgelegt war. Es gab nur eine Programmversion.

> Selbst wenn da ein Bit im Arbeitsspeicher
> umgekippt ist, dann müssten die 25% mit korrekter Funktion vor den
> restlichen Programmiert worden sein.

Ja, der Fehler stellte sich offensichtlich während der Programmierung 
der Mikrocontroller ein.

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ja, der Fehler stellte sich offensichtlich während der Programmierung
>der Mikrocontroller ein.

Der Fehler sitzt vor der Tastatur. Da kannst du annehmen
was du willst ;)

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Steff schrieb:
> Ich erinnere gern an eine Defekte/ falsch Programmierte South(North?)
> Bridge bei älteren PC's . Wurde damals eine Datei > 100 MB von Platte A
> nach Platte B kopiert waren die Daten geschreddert !
>
> Wollte hier nur anmerken, auch auf den PC is nich immer verlass !!!

Es ist ziemlich gut darauf Verlass, dass ein mit dem PC programmierter 
Controller der falsch rechnet nicht das erste Symptom ist mit dem sich 
ein fehlerhafter PC-Speicher bemerkbar macht.

Autor: R. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Beispielerklärung: offener Pullup/Kabelbruch an 25% der Platinen. Beim 
Stecken/rausziehen des Programmierkabels berührst du die offenen 
Eingänge, speist kurz Ladung ein und das Programm liest wieder den von 
dir erwarteten Wert... bis wieder zufällig was kippt und du erneut 
umflashst/berührst...

Autor: lustigerVogel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
sandy, du bist ja ein lustiger Vogel :-)

Funny Story zum gute Nacht Bier ;-)

Nur noch mal, damit ich auch nix verpasst habe:
du programmierst ein paar Geräte. Das Binary lädst du mit deinem 
Programmiertool in deinen "defekten" Arbeitsspeicher also nicht du, 
sondern natürlich dein Betriebssystem und dein Prozess sagt er hätte 
gern Speicher.. ok, nun gut. Also nun programmierst du deinen 
Controller.. und hoppla ein Bit im Arbeitsspeicher ist gekippt.. so ein 
Mist aber auch - verflixt und zugenäht- nun gut, davon weiß unser 
Controller ja nix. Der wird schön programmiert und ist zufrieden - zum 
glück gibt es ja das verify, dass das verflixte Bit aus dem Controller 
zurückliest und - oh - zufälligerweise an exakt die gleiche stelle in 
deinen pc arbeitsspeicher schreibt - was ein glück, dass dein 
arbeitsspeicher so arbeitet! und natürlich kommt das gleiche heraus - 
und die checksumme berücksichtigen wir mal nicht - die stört ja sowieso 
nur :-)

Aber mal ehrlich, wenn ich so einen 75 % bei meiner Firmware entdecke 
beschuldige ich doch nicht den Arbeitsspeicher meines PCs ;-)

Überleg dir mal: Dein uC hat auch einen RAM und der ist beim Start 
deines Controllers uninitialisiert - jedes mal, wenn du die spannung weg 
nimmst und wieder anlegst, kippen die bits im ram neu - und du hast da 
ein anderes bild. Vielleicht benutzt du ja eine uninitialisierte 
Variable oder einen uninitialisierten Pointer... das kann mal gut gehen, 
mal nicht...

;-)

have fun!

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Beim Stecken/rausziehen des Programmierkabels berührst du die offenen
>Eingänge, speist kurz Ladung ein und das Programm liest wieder den von
>dir erwarteten Wert... bis wieder zufällig was kippt und du erneut
>umflashst/berührst...

Das ist ja genau das was Karl Heinz oben schon erwähnt hat.

Beispiel:

Das Programm enthält Routinen zum Empfang per UART.
Im Endprodukt braucht man die aber nicht mehr.
Sie bleiben aber trotzdem drin. Macht ja nix.
Der Empfang erfolgt per Interrupt. Die Interrupt Routine
checkt aber z.B. die Arraygrenzen für den Empfangspuffer
nicht ab. Dann wird noch der Pin für RxD nicht mit
externem oder internem Pullup beschaltet und floatet vor sich hin.

Irgendwann im Betrieb kommt irgendwas dem RxD Pin zu nahe und
löst dauernd den RxD Interrupt aus. Folge: Der Pointer für den
Empfangspuffer läuft Amok im RAM.

Autor: Frank501 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das sind zu viele Zufälle um an solche zu glauben.
Ich halte das definitiv für einen Programmierfehler.

Bitte sag uns noch, von welcher Firma Wir keine Geräte mnehr kaufen 
sollten.

Frank

Autor: bob (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So jetzt hat jeder mal seinen mehr oder weniger vorbelasteten Senf dazu 
abgegeben.

Durchaus kann der Inhalt eines Memory durch verschiedene Probleme 
ungewollt den Zustand ändern.
Das sehen wir des öfteren in Logdateien von Servern die ECC Memory 
benutzen.
Von noch harmlosen "Correctable Memory Error" bis auch zu "Uncorrectable 
Memory Error" ist da alles dabei.

Wobei der erstere Typ ja bei ECC erstmal keine direkten Probleme 
verursacht, sondern man sollte nur sehen wie häufig das auftritt und 
durchaus proaktiv mal den Speicher ersetzen. Bei manchem Hersteller ist 
solches Verhalten auch durch Firmware beinflussbar.

Beim uncorrectable Error kommt es nun darauf an, in welchem 
Speicherbereich das ganze passiert. Tritt es im Programmcode vom Kernel 
auf rauscht die ganze Maschine in den Abgrund, Tritt es "nur" in einem 
Userprogramm im Programmcode auf stürzt der Prozess mit verschiedenen 
Auswirkungen ab.

Auf vielen PC's wird meines Wissens nach ohne ECC Memory gearbeitet, 
teils weil es das Motherboard nicht unterstützt, neuere Boards bieten 
aber inzwischen häufiger an ECC zu unterstützen, oder weil ECC auch ein 
Kostenfaktor ist.

Wenn der Rechner nun ohne ECC Memory betrieben wird, können Memoryfehler 
durchaus vorkommen ohne dass sie vom Betriebssystem oder der Applikation
erkannt werden, ausser es wird Programmcode oder Daten so verändert das
es unzulässige Speicherzugriffe oder dergl. ergibt.

Also wer hier generell behauptet das könnte nicht vorkommen setzt hier 
schon mal Scheuklappen auf.
Je nach Zustand/Alter des PC's dürfte die Wahrscheinlich sich erhöhen 
dass man einem solchen Fehler aufsitzen kann.

Das Szenario wurde ja wie folgt beschrieben:

Schritt1: hex-file von Disk lesen
Schritt2: µC programmieren mit Daten aus dem Memory
Schritt3: Verifikation mit den hexfile-Daten im Memory

Schritt 2 + 3 entsprechend Anzahl der zu programmierenden µC
wiederholen, ggf mit Pausen dazwischen was das Risiko weiter erhöhen 
kann,
da selbst ein Rechner der "nichts tut" schon ziemlich viel macht.
Ggf. laufen noch andere Vorgänge die durchaus Seiteneffekte hervorrufen 
können. Einige der beobachteten Speicherprobleme bei Servern liessen 
sich dadurch mindern oder beheben indem die entsprechenden Memorymodule 
gezogen und neu gesteckt wurden, was auf schlechten Kontakt schliessen 
lies.

Nachdem die Daten demzufolge nicht immer wieder auf ihre Konsistenz 
geprüft wurden bei jedem neuen Vorgang ist das angefragte Szenario
nicht unmöglich. Über die Wahrscheinlichkeit kann man dann auch noch 
tagelang diskutieren.

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
bob schrieb:
> Nachdem die Daten demzufolge nicht immer wieder auf ihre Konsistenz
> geprüft wurden bei jedem neuen Vorgang ist das angefragte Szenario
> nicht unmöglich. Über die Wahrscheinlichkeit kann man dann auch noch
> tagelang diskutieren.
Doch werden sie! Der Programmer liest das programm einaml zurück um zu 
prüfen ob das programmieren gklappt hat und es gibt eine Chekcsumme. Ein 
gekiptes Bit im Arbeitsspeicher oder eins im Kontroller ist dabei egal 
es sollte auffallen... es sei den das Verify arbeitet nicht korrekt!
Die passiert bei JEDEM programmiervorgang.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schon lustig, das hier zu lesen. Trotz vieler Fehler beim Programmieren 
ist es mir nie gelungen, einen Bitfehler im PC nachzuweisen :-)

Meine Empfehlung: den µC-Code mit einer Prüfsumme zu versehen und diese 
beim Programmstart zu verifizieren. Mir ist es lieber, wenn ein Programm 
nicht startet, als wenn es mittendrin 'spinnt'. Das war bei den 
BASIC-Interpretern seinerzeit ein großes Manko: Schreibfehler fielen 
erst dann auf, wenn die Programmstelle ausgeführt wurde - werden sollte.

Auch Daten in EEPROMs können defekt werden, sodaß Prüfsumme und doppelte 
Speicherung auch sinnvoll sein können.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gast schrieb:

> Schon lustig, das hier zu lesen. Trotz vieler Fehler beim Programmieren
> ist es mir nie gelungen, einen Bitfehler im PC nachzuweisen :-)

Weil die üblichen Standard-PCs das meist in Form abstürzender Systeme 
feststellen und defekte Daten nicht sofort als solche erkennbar sind. 
Folglich ist es schon prinzipbedingt kaum möglich, das nachzuweisen. Und 
wenn er dann mal im Bluescreen sitzt, dann ist bekanntlich Microsoft 
Schuld, nach dem Motto "weiss ja jeder, dass Windows gelegentlich 
abstürzt".

Anders sieht es aus wenn man mit Geräten mit ECC-Speicher zu tun hat. 
Das sind letztlich die gleichen Speicherchips wie bei Desktops ohne ECC, 
aber ein paar mehr davon. Da gut betriebene Server auch transiente und 
korrigierte Speicherfehler an die Admins melden, kriegt man das bei 
genug Servern ab und zu mit.

Autor: Bernhard R. (barnyhh)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ A. K.
Vor "ewigen Zeiten" hat meine Tochter - damals 16 - ihren ersten PC 
zusammengestöpselt. Das Ding stieg allerdings bei der 
Betriebssystem-Installation reproduzierbar aus. Speicherriegel hin- und 
hergewechselt; der Fehler wanderte. MEMTEST86 laufen lassen, 
Fehler-Adresse aufgeschrieben, Riegel gewechselt, ...
Tochter hat Speicher zum Händler zurückgebracht und von Fehler 
überzeugt. Neuer Speicher eigebaut, und siehe da: die Kiste lief 
problemlos!

@ Karl heinz Buchegger
>>
Wenn also ein Fehler von 'alleine verschwindet', ohne das eine
nicht-esoterische Erklärung dafür gefunden werden kann, ist Feuer am
Dach. Erfahrene Programmierer richten sich dann schon mal auf eine lange
Nachtschicht ein, in der sie die uninitialisierte Variable, den
Pointer-der-in-den-Wald-zeigt, den Array-Overflow der den Stack
zerschossen hat etc. suchen gehen.
<<

Ob da eine Nachtschicht ausreicht??? Nach meiner Erfahrung kosten 
derartige Fehler mindestens 2 (i.W. zwei) Wochen und verschleißen dabei 
täglich mindestens einen Kollegen, der ausschließlich die Aufgabe hat, 
die "Betriebsblindheit" des Fehler-Suchers zu kompensieren.

Bernhard

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernhard R. schrieb:

> Ob da eine Nachtschicht ausreicht??? Nach meiner Erfahrung kosten
> derartige Fehler mindestens 2 (i.W. zwei) Wochen und verschleißen dabei
> täglich mindestens einen Kollegen, der ausschließlich die Aufgabe hat,
> die "Betriebsblindheit" des Fehler-Suchers zu kompensieren.

Ich wollte Sandy nicht allzusehr frustrieren.


Aber die ganze Diskussion erinnert mich immer mehr an die berühmten 
Compilerfehler, die ausgerechnet und ausschliesslich nur bei Newcomern 
auftreten. Denn das eigene Programm ist ja 100% korrekt.

Aber ich bin da jetzt sowieso raus. Wenn Sandy unbedingt an ihren 
Speicher-Bit-Fehler im PC glauben will, soll sie das tun. Die 
Wahrscheinlichkeit dafür, dass es tatsächlich so etwas war ist nicht 0, 
allerdings auch nicht grossartig größer als 0. Die Erfahrung zeigt, dass 
in 9999 von 10000 Fällen sporadisch auftretendes seltsames Verhalten 
praktisch immer auf einen noch nicht entdeckten Programmfehler 
zurückzuführen ist. Und daran halte ich mich im Zweifelsfall. Ich halte 
die Bit-gekippt Variante für nicht besonders seriös, aber das Gegenteil 
wird sich nicht beweisen lassen.

Autor: bob (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nun, nachdem, wie schon häufig bemerkt wurde, keine gesicherten Aussagen 
darüber getroffen werden können was nun wirklich im µC war ist alles im 
Reich der Spekulation.

Ich sage ja nicht dass es so war, aber es ging ja um die Frage ob es 
jemandem schon passiert ist, also ob es potentiell passieren kann.

Und nachdem dass in unserem Rechenzentrum nicht selten vorkommt,
wir betreiben mehrere hundert Server.
Wir haben mit Fehlern im Main-Memory, CPU-Cache usw. teilweise auch
länger zu tun bis der Hersteller dann den Austausch durchführt.
Teilweise treten Memoryprobleme auch erst zutage wenn man mehr Memory 
als
normal benutzt, oder die Last steigt. Manchmal gibt es Probleme ohne 
dass eine Fehlermeldung zu finden ist oder Diagnosesoftware etwas 
findet. Wenn man Glück hat ist der Fehler persistent und lässt sich 
beliebig wiederholen, manche Fehler sind aber auch "Eintagsfliegen".

Es gibt durchaus auch im Bereich von RAID-Systemen oder Filesystemen 
ähnliche Probleme.

Bislang ist mir nur ein "self-healing" filesystem bekannt, alle anderen 
liefern entweder korrumpierte Daten oder das ganze Filesystem hat schon 
in sich Probleme das die Dateistruktur nicht mehr funktioniert.
Das merkt man dann meist erst wenn der Fehler schon lange drin steckt da 
man ggf. nicht so oft auf die Daten zugreift.
In der heutigen Zeit sind solche Probleme auch für jedermann eine Gefahr 
wenn man nur noch digitalisiertes Material (Urlaubsfotos usw.) 
aufbewahren muss.
Allerdings dürfte sich das Problem bei Festplatten wohl durch "false 
writes" ergeben oder anderen "logischen Fehlern" (bugs) im Code für 
Festplatten oder Filesystemzugriffe.

Autor: Sandy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Aber die ganze Diskussion erinnert mich immer mehr an die berühmten
> Compilerfehler, die ausgerechnet und ausschliesslich nur bei Newcomern
> auftreten. Denn das eigene Programm ist ja 100% korrekt.

In der Hinsicht kann ich Dich beruhigen. Ich blicke mittlerweile auf 
über 30 Jahre Programmiererfahrung zurück. Natürlich weiß ich und kann 
es auch bestätigen, daß mindestens 99,9% aller Fehler im Programm zu 
finden sind.

Ich habe aber auch schon undokumentierte Fehler in Compilern und in 
Mikrocontrollern selbst nachweisen können. Der beschriebene Fehler wäre 
der erste Fehler, für den ich den PC verantwortlich mache.

Autor: Ulli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich finde das wesentliche wurde bereits von kundigen Leuten weiter oben 
erwähnt:

Nämlich dass Speicherfehler bei heutigen PCs durchaus üblich sind. Dies 
liegt daran, dass die Speicher mittlerweile unglaublich gross sind und 
somit die Wahrscheinlichkeit steigt, dass irgend ein Bit kippt. Zum 
anderen liegt es daran, dass die heutigen Speicher-Kondensatoren so 
winzig klein sind und nur noch wenige Elektronen als Speicher haben, 
sodass diese viel anfälliger auf kosmische Strahlung (ja die penetriert 
uns tatsächlich andauernd) sind.

Fakt ist: Bei heutigen PCs kippt immer wieder Mal irgendwo ein Bit. Im 
Normalfall fällt das Niemandem auf. Deshalb ist es heute für Server 
immanent, dass diese ECC-RAMs haben. Früher war das nicht so wichtig, da 
die Speicher eben noch stabiler waren. Mittlerweile haben sogar die 
Cache-Lines der CPU's ECC.

So gesehen ist das obige Szenario auf den ersten Blick gar nicht soo 
unwahrscheinlich.
Unwahrscheinlicher macht es dann eben der Zufall, dass genau dort ein 
Bit kippen musste, wo der Programmcode war.

Bzgl Verify:
Das gekippte Bit würde bei einem Verify nicht auffallen!!!
Da normalerweise die meisten Programmer die CRC immer laufend beim 
Programmieren nebenher berechen. D.h. der PC würde dann einfach die 
Checksumme des bitgekippten Programmcodes rechnen und dieser würde dann 
natürlich mit dem CRC des uC übereinstimmen.
Selbst bei einem 1:1 Verify (alles zurücklesen) würde der Fehler nicht 
auffallen, da ja eben der Programmcode im PC Speicher falsch ist.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ulli schrieb:

> Nämlich dass Speicherfehler bei heutigen PCs durchaus üblich sind.

"Üblich" ist ein starkes Wort. Die meisten Server, auch solche mit zig 
GB Speicher, erleben in jahrelangem Betrieb keinen einzigen Bitfehler.

> sodass diese viel anfälliger auf kosmische Strahlung (ja die penetriert
> uns tatsächlich andauernd) sind.

Wobei die klassische Quelle von strahleninduzierten Bitfehlern jene 
Strahlung ist, die vom Gehäusematerial der Chips selbst produziert wird. 
Nicht die Umweltradioaktivität.

> immanent, dass diese ECC-RAMs haben. Früher war das nicht so wichtig, da
> die Speicher eben noch stabiler waren.

Umgekehrt. Die Zuverlässigkeit ist trotz gesteigerter Kapazität 
gewachsen. Anfangs war die Strahlung des Gehäusematerials viel grösser 
als heute.

> Selbst bei einem 1:1 Verify (alles zurücklesen) würde der Fehler nicht
> auffallen, da ja eben der Programmcode im PC Speicher falsch ist.

Allerdings müsste es sich dabei um eine Art automatisierter 
Programmierung handeln, denn der Fehler ist ja nicht nur einmal 
aufgetreten. Normale Programmierung ist ein einzelner Vorgang, d.h. das 
zu programmierende File wird jedesmal neu geladen, da ist das kaum 
möglich.

Autor: User (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> das zu programmierende File wird jedesmal neu geladen

aus dem Dateicache im RAM

Autor: Ulli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>"Üblich" ist ein starkes Wort. Die meisten Server, auch solche mit zig
>>GB Speicher, erleben in jahrelangem Betrieb keinen einzigen Bitfehler.

OK "üblich" ist relativ. C't hat's Mal ausgerechnet und da kam man dann 
je nach PC auf einen zu erwartenden Fehler von 0.5-3 Jahren.
Das Server eine bessere Quote haben ist auch klar, da diese 
normalerweise mehr Luft übrig lassen und nicht an die Grenze des 
Möglichen gehen, da eben Lebensdauer und Langzeitstabilität wichtiger 
sind. Zudem sind die Boards und Ihre Umgebung meist besser designt.

>>Umgekehrt. Die Zuverlässigkeit ist trotz gesteigerter Kapazität
>>gewachsen. Anfangs war die Strahlung des Gehäusematerials viel grösser
>>als heute.

Kommt darauf an, wie weit du zurückgehst. Es werden nicht ohne Grund 
z.B. für Weltraumelektronik (stark erhöhte Strahlen-Belastung) auch 
Heute noch riesige "alte" Strukturen verwendet.

>>Normale Programmierung ist ein einzelner Vorgang, d.h. das
>>zu programmierende File wird jedesmal neu geladen, da ist das kaum
>>möglich.

Wie bereits erwähnt wurde, wurde während des Programmierens nichts mehr 
von der HD nachgeladen. Selbst wenn die Programmier-SW so geschrieben 
wäre, dass Sie jedesmal das File neu laden würde, würde der Cache des 
Betriebssystems das abfangen.

Autor: Ulli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hab mir gerade noch ein Paper dazu reingezogen. Interessant ist, dass 
die Fehlerrate stark von der Höhe abhängt (mehr kosmische Strahlung)

>>Error rates rise with altitude: SER is 5 times as high at 2600 feet as >>at sea 
level, and 10 times as high in
>>Denver (5280 feet) as at sea level [26]. “SRAM tested at 10,000 feet >>above sea 
level will record SERs
>>that are 14 times the rate tested at sea level [11].”

Autor: Ulli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>Wobei die klassische Quelle von strahleninduzierten Bitfehlern jene
>>Strahlung ist, die vom Gehäusematerial der Chips selbst produziert wird.

Laut Wiki stimmt das nicht wirklich:

Electrical or magnetic interference inside a computer system can cause a
single bit of DRAM to spontaneously flip to the opposite state. It was
initially thought that this was mainly due to alpha particles emitted by
contaminants in chip packaging material, but research [6] has shown that
the majority of one-off ("soft") errors in DRAM chips occur as a result 
of
background radiation, chiefly neutrons from cosmic ray secondaries which
may change the contents of one or more memory cells, or interfere with 
the
circuitry used to read/write them.

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. (prx) schrieb:

> Normale Programmierung ist ein einzelner Vorgang, d.h. das
> zu programmierende File wird jedesmal neu geladen, da ist das kaum
> möglich.

Siehe: Beitrag "Re: Bit im PC-Arbeitsspeicher beim Programmieren gekippt?"

Da schrieb Sandy:

> Beim Starten der Programmierumgebung wurde die Platte nur einmal
> gelesen. Danach kamen alle Daten aus dem PC-Arbeitsspeicher.

Gruß,

Frank

Autor: Christian H. (netzwanze) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es kommt ganz darauf an, welches Programmiertool verwendet wurde.

Und bezüglich cache, kommt es auch drauf an, ob dieser nicht durch 
andere Lesevorgänge anderweitig verwendet werden musste. Wenn ja, wird 
der Cache für weitere Programmiervorgänge wieder von der Platte befüllt.

Das gleiche ist auch, wenn das System Speicher benötigt und diesen nicht 
mehr frei hat. In diesem Fall wird Cache/Speicherinhalt auch gerne auf 
die Platte geswapt.

Nur so als Idee.

Autor: Markus ---- (mrmccrash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich muss die Diskussion noch mal wieder aufwärmen:

http://www.heise.de/newsticker/meldung/Hauptspeich...

Und jetzt?

_.-=: MFG :=-._

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kann ich insoweit bestätigen, als in meiner Server-Praxis harte Fehler 
häufiger sind als temporäre. Besonders bei einer Reihe aus 2 Dutzend 
gleichen Servern, die mittlerweise an die 5 Jahre alt sind und bei denen 
innerhalb der letzten Monate reihenweise defekte Speichermodule 
aufgetreten sind.

Erkennbar ein Serienfehler mit Zeitzünder. Aber die Uhr in dem Zünder 
läuft zu schnell, denn die Wartung läuft 5 Jahre. ;-)

Die übrigen Server (andere Fabrikate, teils bis zu 10 Jahre alt) sind 
dagegen viel friedlicher als die verlinkte Statistik hergibt. Aber so 
ist Statistik eben - meistens ziemlich friedlich wird sie durch einen 
Seriendefekt wieder ausgeglichen. ;-)

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Markus ---- (mrmccrash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Toll, der Link steht zwei Posts weiter oben schon mal...

_.-=: MFG :=-._

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
sorry, hatte extra durchgeblättert und ihn trotzdem übersehen :-(

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.