Hallo,
habe ein sehr seltsames Problem, das so aussieht als würde ein Atmega8
über einen Bootloader 'schlampig' ins Program-Memory schreiben.
Hardware ist ein Atmega8 der über 2 Multiplexer 16 Potis abfragt. Er
empfängt über RX Daten (Midi) und sendet über TX wieder welche raus.
Externer Quartz 8MHz, Spannungsversorgung über Steckernetzteil und 7805.
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
zuverlässig mit den üblichen boot_page_erase() / boot_page_write()-usw.
Befehlen. In den ersten 3 Wochen nach dem flashen tut das Gerät alles
was es soll. Ist Tagelang komplett vom Saft getrennt und funktioniert
nach dem Einschalten absolut zuverlässig. Nach ca. 3 Wochen stürzt es
dann nach dem Einschalten mit immer denselben Symptomen ab. Es hat eine
Startup-Welcome-Blinki-routine für die LEDs, die tut noch, Absturz ist
wohl im Main-Loop. Der Bootloader selbst ist noch gesund, nach einem
erneuten flashen funktioniert das Gerät wieder, nur wie lange?
Ich habe eine Reihe mit 8 Geräten mit jew. leicht unterschiedlicher
Software, davon zeigen derzeit 3 Stück dieses Phänomen. Jeweils pro
Gerät leicht unterschiedliche Symptome aber beim jew. Gerät immer
dasselbe Fehlermuster beim Einschalten. Es sieht so aus als würde der
geflashte Code mit den Wochen zerbröseln. Alle AVRs stammen aus
derselben Bestellung beim großen R.
Hier noch meine Routine zum Schreiben einer Page. page und rx_buffer
sind ausserhalb der Funktion definiert. (Ich sehe gerade daß Interrupts
nicht deaktiviert werden vor dem Schreiben, das kanns doch aber nicht
sein?)
1
voidwrite_buffer_to_flash(){
2
uint16_ti;
3
constuint8_t*p=rx_buffer;
4
eeprom_busy_wait();
5
6
boot_page_erase(page);
7
boot_spm_busy_wait();
8
9
for(i=0;i<SPM_PAGESIZE;i+=2){
10
uint16_tw=*p++;
11
w|=(*p++)<<8;
12
boot_page_fill(page+i,w);
13
}
14
15
boot_page_write(page);
16
boot_spm_busy_wait();
17
boot_rww_enable();
18
}
Kann mir hier jemand eine Richtung weisen für die Fehlersuche?
Herzlichen Dank.
Eine Möglichkeit:
Der Bootloder empfängt Müll (EMV) und überschreibt dann Teile des
Speichers.
Pullups?
POR richtig konfiguriert?
Stromversorgung wirklich Störungsfrei?
> 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
Gregor Z. schrieb:> Wird die Software über SPI geflasht funktioniert soweit alles perfekt.
Flashe mal Applikation + Bootloader über SPI. Wenns dann auch crasht,
wir der Bootloader versehentlich aufgerufen.
Oft sind Bootloader nicht abgesichert und interpretieren Müll auf den
Datenleitungen als Kommandos.
Und natürlich das BOR enablen.
Donnerwetter :) Herzlichen Dank für die vielen Hilfestellungen. Ich
werde den Ansätzen allen mal nachgehen und weiter berichten.
... mich wundert halt die zeitlich schon erstaunlich nah beisammen
liegende Auftritt des Fehlers in 3 von 8 Geräten.
Stefan schrieb:> Kannst Du die fehlerhaften Controller mal auslesen, bevor Du sie neu> beschreibst, und kontrollieren, wo Unterschiede im Flash stehen?
Leider nein, die Fusebits gegen Auslesen sind gesetzt. Ich muss den
Fehler wohl nochmal versuchen zu verifizieren ohne die Lockfuses.
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.
Dein Programm könnte auch durch einen irgendwie gearteten fehlerhaften
Zustand dein write_buffer_to_flash aufrufen und dann wird erstes das
Flash gelöscht. Zum Testen kannst ja mal vor dem boot_page_erase ein
Zeichen an PC senden oder einen freien Ausgangspin setzen.
Wurde diff neuerdings entfunden? Und ob es Muster gibt die einem sehr
viel sagen können wenn man einen Soll-Ist-Vergleich macht. zB wenn immer
ein bestimmtes Bit betroffen ist, oder immer ein bestimmter
Addressbereich zer...rieben wird ...
>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.
Update:
Ich habe nun ein Setup gebastelt, das mehrere der Geräte zugleich ein
paar zigmal den Saft komplett an und wieder abdreht, die Lockbits
rausgenommen und Program-Memory-Dumps verglichen direkt nach dem
Bootloader-Flashen und nach ca. 5x, 20x und 50x Power-On-Reset.
Vorläufiges Ergebnis: grob geschätzt und jew. unregelmässig nach 30-60x
Power-On-Reset werden in den ersten ungefähr 100 Bytes vereinzelt und
jedesmal anders Daten überschrieben, ca. 5-10% hat sich verändert,
unzusammenhängend. Nicht mit 0xff, schön verschieden. Das scheinbare
'Altern' kommt also daher, daß es in ca. 3 Wochen etwa 30 - 60 x
angeschaltet wurde (Minuspunkt wegen off-topic-thread Titel)
Jetzt muss ich nur noch rausfinden warum. Ausser im Bootloader werden
nirgens flash-befehle genutzt. Und wenn beim Start eine bestimmte Taste
nicht gehalten wird, wird der Bootloader übersprungen. Ausserdem
erwartet der Bootloader eine exakt vorgegebene Sequenz und jew. korrekte
Checksummen bevor er tatsächlich write_buffer_to_flash() aufruft.
>Dein Programm könnte auch durch einen irgendwie gearteten fehlerhaften>Zustand dein write_buffer_to_flash aufrufen und dann wird erstes das>Flash gelöscht. Zum Testen kannst ja mal vor dem boot_page_erase ein>Zeichen an PC senden oder einen freien Ausgangspin setzen.
Prima Idee, das könnte ich mal testen. Aber dann sollten doch ganze
Pages verschieden sein, es sind nur einzelne Bytes.
>Pullups?
Ja
>POR richtig konfiguriert?
Äh, 'POR'?
>Stromversorgung wirklich Störungsfrei?
Ich denke schon, eine simple 9V-DC-7805 Schaltung mit den üblichen
100n-Kondensatoren am 7805 In und Out, 10µ dahinter,100µ davor und die
100n-Datenblatt-Abblockkondensatoren direkt am Atmega8. Nur eine
HF-Drossel habe ich (noch) nicht drin.
'BOR' ist der Reset über Brown Out Detection? Habe ich bislang noch
nicht enabled.
Gregor Z. schrieb:> 'BOR' ist der Reset über Brown Out Detection? Habe ich bislang noch> nicht enabled.
Oh Mann - das wird aber auch Zeit.
Zitat aus dem Link den ich gepostet habe:
"Keep the AVR RESET active (low) during periods of insufficient power
supply
voltage. This can be done by enabling the internal Brown-out Detector
(BOD)."
Einhart Pape schrieb:> Gregor Z. schrieb:>> 'BOR' ist der Reset über Brown Out Detection? Habe ich bislang noch>> nicht enabled.>> Oh Mann - das wird aber auch Zeit.
Ganz doof gefragt: was soll der Brown Out Reset aussagen, ausser mir zu
zeigen, daß meine Spannungsversorgung aus irgendeinem Grunde
'zusammenbricht'?
P.S. ich habe die Technote Deines Links gelesen, habe aber (so ganz
laienhaft denkend) keinen Grund anzunehmen, daß die Spannung meiner
Schaltung aus irgendeinem Grunde unter 2.7 V sinken könnte und das
EEprom dadurch nicht sauber beschrieben würde.
Wenn beim Aus- oder Anschalten die Spannung zu klein wird / ist dann
kommt es zu undefinierten Zustanden im Controller. Das soll die brown
out detection verhindern.
Meinst du die Versorgungsspannung baut sich im Mikrosekundenbereich auf
und ab? Was hast du gegen das BOD Flag? Das ist nicht aus Jux und
Dollerei vorhanden.
>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?
Einhart Pape schrieb:> Wenn beim Aus- oder Anschalten die Spannung zu klein wird / ist dann> kommt es zu undefinierten Zustanden im Controller. Das soll die brown> out detection verhindern.
Genau so habe ich es auch verstanden. Der Bootloader wird aber manuell
aktiviert. Bevor irgendetwas geschrieben wird muss er von aussen über RX
mit Daten befüttert werden per Midi von einem PC, manuell von einem
Menschen. Bis dahin sollte die Spannung stabil sein.
der alte Hanns schrieb:>>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?
sorry, vertippt. Nein. Der Bootloader wird manuell enabled indem man
beim Powerup eine Taste hält.
Einhart Pape schrieb:> Meinst du die Versorgungsspannung baut sich im Mikrosekundenbereich auf> und ab? Was hast du gegen das BOD Flag? Das ist nicht aus Jux und> Dollerei vorhanden.
Ich habe nichts gegen das BOD Flag. Ich habe mich bisher nur noch nicht
eingehend damit beschäftigt. Was ich darüber gelesen habe erschien mir
bislang für meinen Anwendungsbereich nicht notwendig. Ich lasse mich
aber gerne eines besseren belehren und mache den Stresstest nochmal
komplett mit enable-tem BOD-Flag.
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
der alte Hanns schrieb:>>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
Habe sie vorsorglich auf die längstmögliche Startuptime gesetzt (weiss
sie nicht auswendig)
> - 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.
stefanus schrieb:> 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.
Ah, so etwas Ähnliches habe ich schonmal gelesen mit der Warteschleife
vor main(). Ich werde das auch mal in die nächste Testrunde mit
einbauen. Danke.
>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.
Tim schrieb:>>Auf Ground schaltende Taster sind direkt mit Portpins verbunden, deren>>interne Pullups aktiviert sind. Software Entprellung.>> Falsch. Mach da einen Externen Pullup dran.
warum externe Pullups? Steht es nicht auch so im Tutorial?
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?
Herrgott, mach einfach den Brownout-Reset rein. Das sind 10s Arbeit.
Danach gibts keinerlei Corruptions mehr. Dein Symptom kommt 100%ig
davon. BTDT...
Aber man kann natürlich auch erstmal tagelang rumdiskutieren ;)
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.
Update 2
ging nicht schneller. Nach dem enablen der BOT auf 4V sind alle 3
getesteten Geräte nach ca. 150 Power-On Resets fehlerfrei, (vorher waren
alle nach ca. 30-50 Resets 'beschrieben'). Ich werde noch etwas
eingehender testen aber ich denke das war es wohl. Hätte nicht gedacht,
daß in dieser Power On/Power Off Phase derart gravierende Dinge
passieren können wie etwa das unautorisierte Benutzen von Teilen meines
Bootloaders.
Herzlichen Dank für die umfassende Hilfestellung und tut mir leid wenn
ich mit einem Anfängerfehler genervt habe. Ich habe wenigstens viel
gelernt.
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
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.
> tut mir leid wenn ich mit einem Anfängerfehler genervt habe.
Och, das Problem hat die Industrie sicher schon viele tausend
Mannstunden und viele 100k$ und Rückrufe gekostet. 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.
BTW: Selbst die Fuse-Settings für den Programmspeicher können sich durch
den Bug ändern. Ich hatte die immer ungeschützt und mit der Corruption
wurde das öfter auch mal auf nicht auslesbar oder nicht mehr
beschreibbar gesetzt. Da half dann auch der Bootloader (der nich
funktioniert hat) nichts mehr...
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.
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.
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.
> daß irgendwelche Default-Einstellungen des> Controllerherstellers irgendeine Auswirkung auf die Funktion des> fertigen Gerätes haben.
Die Default-Einstellung des BOD auf Off hat eine desaströse Auswirkung,
und zwar eine langfristig 100% Chance auf Flash-Corruption.
>> BTW: Selbst die Fuse-Settings für den Programmspeicher können sich durch>> den Bug ändern.> Das ist gleich Doppel-Unsinn.>...> 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.
Tja, du bist ja auch voll der Superhecht.
Atmega8 Manual, Seite 209: "Setting the Boot Loader Lock Bits by SPM"
Damit ist deine Kompetenz zu diesem Thema genug bewertet. Und Tschüss.
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
> Als pauschale Aussage, Blödsinn.
Probiers einfach mal aus, und zwar nicht mit zweimal abschalten, sondern
ein paar tausendmal. Und jetzt komm bitte nicht mit "liegt an der
Stromversorgung" oder "nimm einen Resetgenerator". Das ist ein
neuzeitlicher Microcontroller, der muss ohne externen Schnickschnack
zurechtkommen.
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
Dann hast du Glück gehabt oder Schreib-Zugriffe via SPM in den Fuses
generell disabled. Dann kann ich mir aber auch gleich eine OTP-CPU
kaufen, kommt billiger...
> 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?
Thread beobachten
Seitenaufteilung abschalten