Bootloader flasht schlampig - Code zerbröselt nach 3 Wochen

Ich vermute eher, dass der Bootloader an sich in Ordnung ist, aber zur 
Unzeit aktiv wird.

> Es sieht so aus als würde der geflashte Code mit den Wochen zerbröseln.

Ganz ausschliessen kann man so etwas nicht, aber es ist sehr 
unwahrscheinlich.
Für wesentlich wahrscheinlicher halte ich, das aus irgendeinem Grund 
(z.B.Stacküberlauf) der Bootloader oder irgendwas anderes, das in den 
Flash-Speicher schreibt, ausgeführt wird.

Um Deine Vermutung zu verifizieren, kannst Du ja erstmal den momentanen 
Code zurücklesen. Dann nochmal den Bootloader laufen lassen und den 
neuen Flash-Inhalt mit dem vorherigen vergleichen.

Ich würde tippen, dass der Bootloader zwar korrekt Dein Flash 
beschreibt.
Aber beim Einschalten manchmal fehlerhaft meint, Dein Flash löschen zu 
müssen.

Eine andere Möglichkeit ist, daß Deine Firmware ab und an abstürzt und 
dabei in den Bootloader-Code springt und diesen teilweise ausführt.

Kannst Du die fehlerhaften Controller mal auslesen, bevor Du sie neu 
beschreibst, und kontrollieren, wo Unterschiede im Flash stehen?

Gruß Stefan

Vor diesem Vorgehen würde ich wegen des Aufwandes zurückschrecken.

"...doch ein Dump auf hundert Seiten
kann Entsetzen nur verbreiten."

Hans schrob:
>"...doch ein Dump auf hundert Seiten
>kann Entsetzen nur verbreiten."

Jedoch zum schnellen Fehlersuchen
kann man doch Studenten buchen!

;-)
MfG Paul

für Paul Baumann
"A great heap of paper lies on the floor, a continuous sheet of computer 
paper streaming out of the carriage of Gollum's system console. 
Stretched out, the sheet would run across the room and back again 
several times. You could fit a fairly detailed description of American 
history from the Civil War to the present on it. Veres sits in the midst 
of this chaos, the picture of the scholar. He's examined it all."
Kidder: The Soul of a New Machine

Those were the days, my friend

(nur ganz am Rande: haben Sie Oliver Sacks gelesen?)

-----------

Aber zurück: Welches Resultat sollte ein Dump-Vergleich erbringen ausser 
dem, wovon alle hier ausgehen, dass nämlich der Ist- nicht dem 
Soll-Zustand des Programmes entspricht; dass ein eventuelles 
Fehler-Muster tiefergehende Rückschlüsse auf die Fehler-Ursache erlaubt, 
halte ich für unwahrscheinlich. Besser die Zeit und gute Laune in die 
Analyse der anderen hier genannten Faktoren investieren.

Würde auch versuchen den µC zu stressen um den Fehler zu reproduzieren.
Aber wenn du ihn reproduziert hast kann man den Flash natürlich aulesen 
und gucken was passiert ist. Wenn z.B. nur ein Paar oder nur ein 
Bitdreher drin ist, wirds wohl der Bootloader nicht sein. Wenn da ne 
ganze Seite 0xFF zu finden sind wo normalerweise was anderes ist ist der 
Bootloader wohl irgendwie aufgerufen worden. Werden ansonsten SPM 
Befehle benutzt außerhalb des Bootloaders bzw. BOD aktiviert (auf einem 
sinnvollem Spannungslevel).

der alte Hanns schrieb:
> Aber zurück: Welches Resultat sollte ein Dump-Vergleich erbringen ausser
> dem, wovon alle hier ausgehen, dass nämlich der Ist- nicht dem
> Soll-Zustand des Programmes entspricht; dass ein eventuelles
> Fehler-Muster tiefergehende Rückschlüsse auf die Fehler-Ursache erlaubt,
> halte ich für unwahrscheinlich. Besser die Zeit und gute Laune in die
> Analyse der anderen hier genannten Faktoren investieren.

Nun, zum einen gehen sicher nicht alle davon aus, das ein Unterschied 
besteht.
Der TO selbst scheint davon auszugehen, einige Antworter halten das für 
gut möglich, einige andere, durchaus die Mehrheit (denke ich) nicht.
Wenn kein Unterschied besteht, dann ist die Wahrscheinlichkeit groß, 
dass es sich um einen der anderen Faktoren handelt.
ABER: Davon müssen nicht nur die Antworter sondern auch der TO überzeugt 
werden.

Zum zweiten ist, zumindest für mich, Deine Suggestion von einer langen 
Schlange Papier nicht so recht plausibel. Niemand würde das ausdrucken. 
Wie kommst Du darauf, das man das so macht?

Zum dritten ist das Verfahren so ziemlich das kürzeste im Vergleich zur 
Auffindung möglicher anderen Ursachen. Es bietet darüber hinaus noch den 
Vorteil, dass evtl. Probleme beim Auslesen eher noch in die Richtung 
dieser anderen Ursachen deuten würde.

Uwe schrieb:
> Aber wenn du ihn reproduziert hast kann man den Flash natürlich aulesen
> und gucken was passiert ist.
Nun, er hat ja gerade einen uC vorliegen, bei dem das Problem schon 
aufgetreten ist. Das kann er ja, mit einem vergleichen den er frisch 
geladen hat, mit dem Image, wie es nach der Ausführung des Bootloaders 
entsteht (Notfalls mit einer Simulation).

Uups, da ist mir ein Fehler unterlaufen.
Statt:

>Der TO selbst scheint davon auszugehen, einige Antworter halten das für
>gut möglich, einige andere, durchaus die Mehrheit (denke ich) nicht.

sollte es heissen:

>Der TO selbst scheint davon auszugehen, einige Antworter, das kann durchaus 
durchaus die Mehrheit sein (denke ich), halten das für
>gut möglich, einige andere nicht.

Jedenfalls ist die Überprüfung der anderen Möglichkeiten wesentlich 
aufwendiger (wenn sie hier im Forum geschehen soll, auf jeden Fall).
Man müsste ein Foto von dem Aufbau, einen Schaltplan haben, ansehen und 
diskutieren und vermutlich noch eine Diskussion über Sinn und Unsinn von 
Abblockkondesatoren führen.

> Nun, er hat ja gerade einen uC vorliegen, bei dem das Problem schon
> aufgetreten ist.

Er hat aber auch geschrieben das nach dem erneuten Flashen das problem 
weg ist.

Hast Du mal geschaut was das Ding nach einem Watchdog Reset macht? Ich 
durfte schon leidvoll erleben das das nicht immer dasselbe sein muss wie 
bei Power on Reset.

Das würde auch zur langen fehlerfreien Zeit passen.

viel Erfolg
Hauspapa

Uwe schrieb:
>> Nun, er hat ja gerade einen uC vorliegen, bei dem das Problem schon
>> aufgetreten ist.
>
> Er hat aber auch geschrieben das nach dem erneuten Flashen das problem
> weg ist.

Er hat aber auch geschrieben: "davon zeigen derzeit 3 Stück dieses 
Phänomen". Unter "derzeit" habe ich "jetzt, hier und heute" verstanden.

Falls er die allle schon neu geflasht hat, dann ist's natürlich Essig. 
Dann kann man sich gleich auf die anderen möglichen (Hardware-) Ursachen 
konzentieren.

>empfängt über RX Daten (Midi)
>Wird die Software über SPI geflasht funktioniert soweit alles perfekt.
>Gerät ausgeschaltet monatelang in die Ecke stellen, anschalten und es
>funktioniert noch. Ähnliche Eigenbauten habe ich seit Jahren im
>fehlerfreien im Einsatz.
>Nun hat das Teil kürzlich auch einen Bootloader bekommen, der die
>Firmware über RX einlesen und flashen kann. Auch der funktioniert
>Nach ca. 3 Wochen stürzt es dann nach dem Einschalten mit immer denselben 
>Symptomen ab
>Der Bootloader selbst ist noch gesund, nach einem
>erneuten flashen funktioniert das Gerät wieder

Es scheint also doch so, dass der Bootloader unter undefinierten 
Bedingungen aktiv wird, und ich würde gezielt hier ansetzen.
Nach meiner Erfahrung ist eine Dump-Analyse eine der letzten Zufluchten, 
aber jeder hat seine eigenen, für ihn passenden Methoden entwickelt, 
letztlich muss es für Gregor Z. stimmen.

>EEprom dadurch nicht sauber beschrieben würde.

? - Was hat das mit dem Problem zu tun? Läuft der Controller in 
Abhängigkeit vom EEPROM in den Bootloader?

Flash Speicher verlieren manchmal ihre Daten, wenn man sie liest, 
während die Spannungsversorgung zu niedrig oder instabil ist.

Mir ist das mit den Speicher eines Ethernet Controllers in kombination 
mit einem Handy-Ladegerät (als Netzteil) hundert mal passiert, bis ich 
dahinter gekommen bin.

Brown-Out Detection in Kombination mit einem 500ms Sleep am Anfang der 
main() Funktion löste das Problem zuverlässig.

>Der Bootloader wird manuell enabled indem man
>beim Powerup eine Taste hält.

Dann stellen sich zwei Fragen:
- sind die fuse-bits für das power-up-timing korrekt
- wie sieht die Hardware um diese Taste herum aus

>Auf Ground schaltende Taster sind direkt mit Portpins verbunden, deren
>interne Pullups aktiviert sind. Software Entprellung.

Falsch. Mach da einen Externen Pullup dran.

Und das mit der BOD Fuse solltest du echt machen.
Habe da auch so meine Erfahrungen.....

Delay am anfang von main brauchst du nicht.

Und wie viele µs vergehen zwischen pullup ein und Port auslesen?

Gregor Z. schrieb:
> Der Bootloader wird manuell enabled indem man
> beim Powerup eine Taste hält.

...oder (mit etwas Pech) beim brown-out: während die Versorgungsspannung 
allmählich wegdämmert, werden einige Bits schwach, während die meisten 
noch weiterarbeiten. Wenn zufällig Bits im oberen Teil des Program 
Counter von einem Schwächeanfall betroffen sind, "springt" die CPU 
einfach mal irgendwohin, mit etwas Pech auch irgendwo in den Bootloader.

Nosnibor schrieb:
> während die Versorgungsspannung
> allmählich wegdämmert, werden einige Bits schwach, während die meisten
> noch weiterarbeiten.

Vielleicht den Bits ein Erfrischungsgetränk reichen?
Ich dämmer auch gleich weg :-(

Peter Dannegger schrieb:
> Flashe mal Applikation + Bootloader über SPI.
> ...
> Und natürlich das BOR enablen.

Wurde das schon gemacht?
Wenn nein, warum nicht?

Ich sehe das auch so wie Nosnibor:

Das grössere Problem ist das Ausschalten. Je nach Kapazitäten an Deiner 
Versorgung kann sich das ziemlich lange hinziehen. Und in dieser Zeit 
kann die CPU ziemlichen Unsinn veranstalten. Daß nur die ersten ~ 100 
Byte betroffen sind, kann darauf hindeuten, daß die CPU mit Unsinn 
anfängt, dafür aber nicht mehr viel Zeit hat ...

@ der alte Hanns:
Ich finde es aufschlussreich, wo die Daten im Flash überschrieben 
werden: nur am Anfang, mittendin, alle zusammen oder nur ein parr 100 
...
Ein typisches Beispiel: Speicherstelle Null des Eeproms ist immer der 
erste Kandidat für einen BOR-Fehler. Bei früheren Atmels war die 
EE-Adresse 0 fast nicht benutzbar.

Für ein Runaway der CPU spricht auch, daß das Problem erst auftritt, 
seitdem Code zum Ändern des Flash vorhanden ist.

Gruß Stefan

an Stefan

Zugegeben.
Aber können Sie sich auf dieses einen Reim machen? Ich erstmal nicht.

>Aber dann sollten doch ganze
>Pages verschieden sein, es sind nur einzelne Bytes.

Kann sein, daß boot_page_write(0) aufgerufen wird, ohne die page vorher 
zu löschen. Dann werden nur Bits von 1 auf 0 geändert (oder war es 
andersherum, Atmega ist schon so lange her ..?), je nachdem, was im 
page-Buffer steht.

Auf jeden Fall sollte das Einschalten des BOR helfen.

Gruß Stefan

an Stefan

Soll das heißen, dass in diesem Abschalt-Delirium Zeit genug ist, eine 
Seite zu lesen und verändert zurückzuschreiben? Merkwürdig.

der alte Hanns schrieb:
> an Stefan
>
> Soll das heißen, dass in diesem Abschalt-Delirium Zeit genug ist, eine
> Seite zu lesen und verändert zurückzuschreiben? Merkwürdig.

Ein einziger Schreibvorgang reicht doch, um Unheil anzurichten.
Da muß doch keine komplette Seite gelesen und wieder geschrieben werden.
Und wenn die Spannung langsam genug sinkt, ist auch die Zeit größer, wo 
undefinierte Aktionen passieren können.

Das verstehe ich nicht. Ich hatte das Datenblatt so interpretiert, dass 
nur eine ganze Seite geschrieben werden kann. Und wenn, wie Gregor Z. 
schreibt, lediglich einzelne Bytes, und nicht mal nur jeweils die 
ersten, verändert sind, so muss doch vorher die Seite gelesen worden 
sein.

der alte Hanns schrieb:
> Das verstehe ich nicht. Ich hatte das Datenblatt so interpretiert,
> dass
> nur eine ganze Seite geschrieben werden kann. Und wenn, wie Gregor Z.
> schreibt, lediglich einzelne Bytes, und nicht mal nur jeweils die
> ersten, verändert sind, so muss doch vorher die Seite gelesen worden
> sein.

Kleines Mißverständnis :-)
Ich hatte es so gemeint, daß ja während des Schreibvorganges durchaus 
die Spannung gesunken sein kann, daß der Schreibvorgang nicht vollendet 
wurde. Deswegen meinte ich, daß ja schon der Beginn des Schreibvorganges 
reicht, wenn nur ein oder wenige Bytes geschrieben sind.

"Code zerbröselt nach drei Wochen"...mehr Zement in die Mischung und 
weniger Sand...

der alte Hanns schrieb:
> so muss doch vorher die Seite gelesen worden
> sein.

Nein, muss sie nicht.
Die Schreibfunktion kann den Wert eines Bits nur von 1 auf 0 ändern, 
nicht umgekehrt (das kann die Löschfunktion).
Wenn im Flash also in einem Byte der Wert 0x03 steht und Du den Wert 
0x07 hineinschreibst passiert - nix. Wenn Du statt dessen 0x01 
hineinschreibst, änder sich der Wert im Flash von 0x03 auf 0x02.

an Andreas

Das klingt pausibel, danke für die Erläuterung.

Georg A. schrieb:

> Das Hauptproblem ist,
> dass Atmel sich wohl nicht dazu durchringen kann, eine ganz dicke fette
> Warnung ins Datenblatt zu bringen oder den BOD gleich per Default
> schonmal auf die niedrigste Stufe zu programmieren.

Unsinn. Bei einem professionell entwickelten Gerät sollte es niemals 
vorkommen, daß irgendwelche Default-Einstellungen des 
Controllerherstellers irgendeine Auswirkung auf die Funktion des 
fertigen Gerätes haben.

> BTW: Selbst die Fuse-Settings für den Programmspeicher können sich durch
> den Bug ändern.

Das ist gleich Doppel-Unsinn.

1) Irreguläres Verhalten bei einem Brownout ist kein "Bug", sondern 
normales Verhalten. Nicht nur bei AVRs, sondern bei allem, was 
elektronisch rechnet. Jeder, der das Grundlagenstudium erfolgreich 
überstanden hat, sollte nicht nur wissen, DASS das so ist, sondern sogar 
WARUM es so ist.

2) Die Lockbits sind zusammen mit den Fuses genau die Sachen, die von 
Brownout-Schäden praktisch nie betroffen sind, weil sie eben deshalb als 
Fuse implementiert sind, damit niemals schreibend aus dem MCU-Core 
darauf zugegriffen werden kann.

Wenn zu idiotischer Entwicklung bezüglich der Brownout-Problematik 
allerdings noch genau dieselbe Idiotie bei der Reset-Beschaltung und der 
Auslegung der Stromversorgung kommt, dann kann es auch mal die Fuses 
oder Lockbits verstellen. Dazu ist aber wirklich komplette Unfähigkeit 
des Entwicklers nötig, der muß alles, aber wirklich auch alles so 
grundfalsch machen, was man es nur machen kann.

Der Typ ist dann krass unfähig->feuern und Schadensersatzklage gleich 
hinterher. Schließlich hat er von seinem AG Zahlungen entgegengenommen 
für eine Leistung, die er definitiv nicht zu erbringen in der Lage war, 
nämlich kompetente Entwicklungsarbeit.

Hi

>Die Default-Einstellung des BOD auf Off hat eine desaströse Auswirkung,
>und zwar eine langfristig 100% Chance auf Flash-Corruption.

Als pauschale Aussage, Blödsinn.

MfG Spess

Spricht was gegen das grundsätzliche Setzen von "Brown Out Detection" ?
Gibt es Situationen, mit denen man sich Probleme einhandeln kann?

Ansonsten habe ich wieder was gelernt und werde BOD immer setzen.

Danke und Gruß
Thomas

an Thomas

Stromverbrauch: z.B. wenn man bei einem ATmega16 einen Netzausfall mit 
einem Goldcap überbrücken will, fallen die ca. 15 uA ins Gewicht.

Hi

>Probiers einfach mal aus, und zwar nicht mit zweimal abschalten, sondern
>ein paar tausendmal.

Reichen auch ein paar tausend Geräte mit bis zu 15 Jahren im 
industriellen Einsatz?

MfG Spess

> Spricht was gegen das grundsätzliche Setzen von "Brown Out Detection" ?
> Gibt es Situationen, mit denen man sich Probleme einhandeln kann?

Jepp, zumindest in meinem Fall:

Billige Brushlessregler im Modellbaubereich mit einfacher 
uC-Spannungsversorgung oder aber auch mit getakteter Spannungsversorgung 
mittels StepDown, der nicht schnell genug ausregelt. Im Moment der 
Vollgasstellung bricht die uC-Spannungsversorgung um 1V ein und der Chip 
wird resetet> Neuausrichtung der Neutralgasstellung im Flug usw. nötig. 
Hab auf diese Weise den Flieger fast zwei mal ums Leben gebracht. Hab 
den Regler von Schrumpfschlauch befreit und siehe da ein ATmega8, 
eigenen Reglercode drauf gejagt, BOD aus und das Ding funktioniert wie 
es soll, trotz immer noch vorhandenem leichten Spannungseinbruch.
Nun gut, in diesem Fall ist es natürlich schlicht und einfach eine 
fehlkonstruierte Spannungsversorgung, die Funktion des BODs im 
OFF-Zustand hilft aber, diesen Mangel einigermaßen zu beseitigen.
Das hierbei auch ein Fehlverhalten des uCs fast schon provoziert wird, 
ist natürlich klar, allerdings habe ich bisher mit dieser Konfiguration 
im letzen Sommer bei über 50 Flügen keinen einzigen ungewollten 
Reglerreset mehr gehabt.

Alex schrieb:
> Im Moment der
> Vollgasstellung bricht die uC-Spannungsversorgung um 1V ein

dann könnte man BOD ja auch auf 2,x Volt setzen.
Gibt es sonst irgendeinen Grund warum man das Bit überhaupt braucht,
also warum BOD nicht fest verdrahtet ist?