-
        

Seite 1 von 3 123 LetzteLetzte
Ergebnis 1 bis 10 von 21

Thema: EEPROM Beständigkeit

  1. #1
    Erfahrener Benutzer Roboter Experte Avatar von ikarus_177
    Registriert seit
    31.12.2007
    Ort
    Grein
    Alter
    24
    Beiträge
    601

    EEPROM Beständigkeit

    Anzeige

    Hi,

    ich speichere im EEPROM eines M32 diverse Kalibrierungs- und Interpolationsdaten für die Ansteuerung meiner Servos. Diese Daten machen pro Hexa-Bein 37 Bytes aus, die nach Abschluss der Kalibrierung im EEPROM abgelegt werden. Beim nächsten Programmstart lädt der Bot diese Daten wieder, um die Servos korrekt ansprechen zu können.
    Die EEPROM-Files habe ich mit Bascom als *.bin - Dateien am Computer gesichert, um sie gegebenenfalls neu aufspielen zu können.

    In den meisten Fällen funktioniert dieses Verfahren auch. Allerdings tritt es manchmal auf, dass anscheinend falsche Werte für einen Servo geladen werden, dieser Servo fährt dann entweder an den Endanschlag oder bewegt sich überhaupt nicht. Nach einem erneuten Aufspielen des (gesicherten) EEPROM - Inhaltes funktioniert alles wieder wie gewohnt. Noch hab ich kein System hinter diesem Verhalten beobachten können - es tritt bei unterschiedlichen Controllern auf, und wie es derzeit den Anschein macht - rein zufällig.

    Ist dies ein "normales" Verhalten eines EEPROM's, falls nein, womit kann dieses Verhalten begründet werden? Hat jemand eine Idee?

    Viele Grüße
    ikarus_177

  2. #2
    Erfahrener Benutzer Robotik Visionär
    Registriert seit
    26.11.2005
    Ort
    bei Uelzen (Niedersachsen)
    Beiträge
    7.942
    Das gegelgentliche überschreiben von EEPROM Inhalten kann vor kommen, wenn die Versorgungsspannung langsam sinkt und der µC dann noch ein paar Befehle mit viel zu kleiner Spannung ausführt. Dabei passiert es gelegentlich auch mal das das EEPROM (und angeblich gelegentlich auch mal das flash) überschrieben wird. Meistens die Speicherstelle 0. Die erste Abhilfe ist es nicht gerade das Byte an der Adresse 0 zu nutzen.

    Die richtige Lösung ist es den Brownout Detektor zu aktivieren. Oder wenn keinen internen gibt (alte chips) einen externen Brownoutdetektor/Spannungswächter zu nutzen.

  3. #3
    Erfahrener Benutzer Roboter Experte Avatar von ikarus_177
    Registriert seit
    31.12.2007
    Ort
    Grein
    Alter
    24
    Beiträge
    601
    Hi,

    ... Speicherstelle 0 ... | ... überschrieben wird ...
    Das habe ich in der Bascom-Dokumentation auch gelesen und deshalb die Adresse 0 unbelegt gelassen. Daran kann es also nicht liegen, da bis jetzt nur die höheren Adressen (~18 - ~ 36) fehlerhaft sind.

    Ist denn die Brown-out Detection bei den ATMegas standardmäßig deaktiviert? Sonst werde ich sie am Wochenende einfach mal einschalten, vielleicht ergibt sich ja dann etwas.

    Viele Grüße

    EDIT: So, hab grad die Brown - out - Schwelle bei allen beteiligten Controllern auf 4V eingestellt (war die höchste auswählbare Spannung im myAVR ProgTool). Reicht denn diese Schwelle aus?

  4. #4
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    15.08.2005
    Alter
    26
    Beiträge
    590
    Zitat Zitat von Besserwessi
    Das gegelgentliche überschreiben von EEPROM Inhalten kann vor kommen, wenn die Versorgungsspannung langsam sinkt und der µC dann noch ein paar Befehle mit viel zu kleiner Spannung ausführt.
    Kann bei guter Programmierung nicht vorkommen!!
    NOTHING IS IMPOSSIBLE

    Ihr werdet alle ver-apple-t!

  5. #5
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    08.07.2004
    Ort
    Südhessen
    Beiträge
    1.312
    @sdz55: Du weißt nicht, wovon Du redest.
    Besserwessi hat recht, dass die Überschreibung von Inhalten nicht-flüchtiger Speicher bei sinkender Versorgungsspannung ungewollt und programmunabhängig passieren kann.

    Bitte antworte nur, wenn Du was beizutragen hast.

  6. #6
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    15.08.2005
    Alter
    26
    Beiträge
    590
    Zitat Zitat von thewulf00
    @sdz55: Du weißt nicht, wovon Du redest.
    Besserwessi hat recht, dass die Überschreibung von Inhalten nicht-flüchtiger Speicher bei sinkender Versorgungsspannung ungewollt und programmunabhängig passieren kann.

    Bitte antworte nur, wenn Du was beizutragen hast.
    Danke gleichfalls... Wenn du Brown-Out detection kennst, dann wüsstestdu dass ich recht habe.. Oder wie wärs denn mit der Stromausfallzeit? Bei Stromausfall hast du eine Flanke von ein paar Nano-Sekunden, dazu gerechnet noch die Kapazität oder eventuell Stützbatterien... Ich weiss sehr wohl wovon ich rede mein lieber.
    NOTHING IS IMPOSSIBLE

    Ihr werdet alle ver-apple-t!

  7. #7
    Erfahrener Benutzer Robotik Visionär
    Registriert seit
    26.11.2005
    Ort
    bei Uelzen (Niedersachsen)
    Beiträge
    7.942
    Durch die Abblockkondensatoren dauert es oft relativ lange bis die Spannung von etwa 4 V (darüber sollte noch alles oK sein) bis auf etwa 1 V (darunter sollte nicht mehr viel passieren) fällt. Das kann durch aus ausreichen, das die CPU noch ein paar relativ unkontrollierte Operationen ausführt, die auch nicht unbedingt was mit dem Programm zu tun haben müssen. Selbst wenn das Programm nie das EEPROM nutzt kann (muß aber nicht) so mehr oder weniger zufällig das EEPROM verändert werden.

    Es ist dabei gut möglich das einige Exemplare des Chips keine sichtbaren Fehler zeigen und einzelne Chips bevorzugt eine EEPROM Addresse verändern, je nach dem welches Gatter zu erst aufgiebt oder Störungen einfängt. Wegen des eher zufälligen und seltenen Fehlers hatte man bei den ersten µCs auch noch keinen Brownout Detektor drin.

    Der Brownout detektor verhindert gerade solch unkontrolliertes Verhalten in dem der µC bei zu kleiner Spannung im Rest-zustand bleibt.

    Bei ganz kurzen Spannungseinbrüchen wegen fehlender Enkoppelkondensatoren hat man dann ein anderes Problem, dass man aber auch lösen kann.

    Edit: zum Nachlesen: Atmel application Note AVR180

  8. #8
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    11.12.2007
    Ort
    weit weg von nahe Bonn
    Alter
    33
    Beiträge
    2.378
    @SDZ ich muss dir auch wiedersprechen, brown out schützt NICHT

    selbst wenn ich extern nen reset veranlasse ( OPV-schaltung mit bandgap)... eeprom nutzung KANN kritisch sein, selbst nur beim lesen veränder sich bei mir die werte, wenn die spannungsversorgung mal nicht ganz hinhaut oder ich nen wackler beim anschluss habe

    hm hab das note mal überflogen, die einschaltverzögerung ist sehr interessant das problem trat bisher fast nr auf wenn ich beim einschaten ein starkes prellen hatte (oder anstecken)

    by the way, der ausdruck "bei guter Programmierung" passt ja auch net ganz, ist ja hardware net software

  9. #9
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    15.08.2005
    Alter
    26
    Beiträge
    590
    ja aber du kannst die BrownOut auch ausschalten
    Das ein eeprom in einem integrierten chip wie einem uC keine hundert prozentige lösung darstellt ist auch mir klar. Fakt ist, dass man solche speicher auslagern und mit stützbatterien sichern sollte. Dann kann man dazu vielleicht ein eeprom nehmen welches sich per hardware (Pin) schützen lässt
    mfg
    NOTHING IS IMPOSSIBLE

    Ihr werdet alle ver-apple-t!

  10. #10
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    11.12.2007
    Ort
    weit weg von nahe Bonn
    Alter
    33
    Beiträge
    2.378
    ich bin bis heute nicht dazu gekommen die idee zutesten, aber wie wäre es wenn ich den controller, an allen aktiven pins über .... sagen wir mal mit dioden entkopple (bei einem bus müsste es wohl schon ein optokoppler sein) und in der µC-versorgung einen relativ dicken kondensator verbaue, der auch mnit einer diode gegen entladung durch die restlichen schaltung geschützt wird ... wnen ich jetzt ne externe spannungsüberwachung dran habe und nurnoch den controller aus dem kondensator speisen muss, während der rest der schaltung unter spannungsmangel leidet, müsste doch theoretisch ein sicheres abschalten gewährleistet sein?!? zusätzlich ne zeitliche einschaltverzögerung einbauen

Seite 1 von 3 123 LetzteLetzte

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •