Ich verstehe die Welt nicht mehr...

[Zentauro]

Hallo,

ich habe ein Projekt, bei dem ich mir einige Servopositionen im EEPROM speichere. Dies funktioniert wunderbar und lesen kann ich sie auch wieder.
Der Leseprozess geschieht immer gleich nach dem Hochlauf.

Nun der Skandal: Bei jedem 10.Mal einschalten, steht nix mehr im EEPROM - was mach ich bloss falsch??? Es ist Gewiss kein Programmfehler, ich denk eher an irgendwelche EMV-Probleme, weil ein relativ großer Motor in unmittelbarer Nähe ist.

Hat irgendwer eine Ahnung, bzw. kennt irgendjemand das Phänomen der verschwindenden EEPROM Daten?

Stromversorgung kommt von einem Akku, also sollte es bezüglich Versorgung auch keine Schwankungen geben...

Zur Sicherheit trotzdem das Programm:

.
.
.
'************************************************* *****************************
' Main Program
'************************************************* *****************************
Main:
Readeeprom Servo1opened , 0
Readeeprom Servo1closed , 1

If Switchpressed = 1 Then
Print "Servo SetUp Mode "
Call Ledacknowledge()
Wait 2
'first set opened state
Bitwait Switchpressed , Reset
While Switchpressed <> 1
Servovalue = 10.2 * Controlvalue
Servo(1) = Servovalue
Wend
Call Ledacknowledge()
Call Ledacknowledge()
Bitwait Switchpressed , Reset
Waitms 500

Print "Set opened Value: " ; Servo(1)
Writeeeprom Servo(1) , 0
Servo1opened = Servo(1)

'then set closed state
While Switchpressed <> 1
Servovalue = 10.2 * Controlvalue
Servo(1) = Servovalue
Wend
Call Ledacknowledge()
Bitwait Switchpressed , Reset
Print "Set closed Value: " ; Servo(1)
Writeeeprom Servo(1) , 1
Servo1closed = Servo(1)
End If
.
.
.

==> ist übrigens ein MEGA8 und ich nutze das interne EEPROM

Danke, lg

[for_ro]

Hallo Zentauro,
benutzt du das interne EEPROM?
Da gibt es wohl ein Problem mit den ersten Bytes. Die werden beim Booten manchmal gelöscht. Evtl. auch nur bei bestimmten AVRs.
Ich habe die ersten 8 Bytes deshalb bei mir ausgelassen.

Gruß

Rolf

[Zentauro]

Hallo Rolf,

danke für die Info - passiert das aber nicht immer oder??

lg

[for_ro]

Hallo Zentauro,
ich kann mich leider an die genauen Zusammenhänge nicht mehr erinnern.
In meiner Anwendung hatte ich die Adressen der DS1820 (jeweils 8 Byte) im EEPROM abgelegt. Von Zeit zu Zeit war die erste Adresse nach dem Neustart kaputt. Seit ich die ersten Bytes auslasse, ist das Problem nie mehr aufgetreten.
Vielleicht weiss ja noch jemand anderes genaueres zum Thema.

Gruß

Rolf

[enterprise30]

Das hab ich andere Stelle irgendwo auch schonmal in nem Buch oder Datenblatt gelesen (Erste Stelle im Eprom löscht sich).
Auf die schnelle find ich nur das: (Datasheet Atmega8, Seite 21)

During periods of low VCC, the EEPROM data can be corrupted because the supply voltage
is too low for the CPU and the EEPROM to operate properly. These issues are the
same as for board level systems using EEPROM, and the same design solutions should
be applied.
An EEPROM data corruption can be caused by two situations when the voltage is too
low. First, a regular write sequence to the EEPROM requires a minimum voltage to
operate correctly. Second, the CPU itself can execute instructions incorrectly, if the supply
voltage is too low.
EEPROM data corruption can easily be avoided by fol lowing this design
recommendation:
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). If the
detection level of the internal BOD does not match the needed detection level, an
external low VCC Reset Protection circuit can be used. If a reset occurs while a write
operation is in progress, the write operation will be completed provided that the
power supply voltage is sufficient.

[Ceos]

kann ich bestätigen, entweder du schaltest ne art "einschaltverzögerung" an RESET damit der µC ne halbe sekunde oder so im reset verharrt, oder du machst die BOD lösung, also wenn BOD(2.7V sollte reichen) pin auf high geht den reset auf low ziehen (oder wars wenn BOD auf low geht ???? habs schon lange net mehr in der form aufgebaut sry)

[stefan_Z]

Und bezieht sich das jetzt auf das gesamte EEP oder nur die ersten Bytes?
Könnte der OP das nochmal mit Bytes 8 bis irgendwas testen, ohne den Rest zu ändern?

[Ceos]

ich vermute das was beim lesen schiefgeht, also würde es sich auf den gesammten EEP auswirken, weis ja nciht wie for_ro gemacht hat, aber gut möglich das bei ihm nur die ersten lesevorgänge den EEP kompromittiert haben und wenn er während der zeit dummybytes liesst die er verwirft ist klar das der fehler icht auffällt aber dennoch stattfindet ... versuchs mal mit ner einschaltverzögerung und berichte dann was passiert

[Zapo.]

wie kann man den die ersten Bytes eigentlich ausschließen wenn man z.B. mit ERAM Variablen arbeitet????
dann hat man ja keinen einfluß wo BASCOM dann die Variable hinlegt!

wenn man mit writeeeprom var, adress arbeitet kann ich ja eine (muß ich sogar) angeben!

aber ansonsten gehts wohl nicht, oder?

(PS: man könnte natürlich beim Programmstart einen String oder Byte Array von 10 - 16 Bytes in das EEPROM schreiben, somit hätte man eine hohe Wahrscheinlichkeit das die ersten Byte belegt sind, aber das ist ja wohl kaum im INterresse des Programmieres so Speicher zu verschwenden...)

[BlueNature]

Servus Zapo.,

Du kannst einfach in der Reihenfoge der Vergabe der Eeprom-Variablen 2x Dummy schreiben und danach die restlichen ablegen

Dim Dummy1 As ERAM Byte
Dim Dummy2 As ERAM Byte
Dim DeineVar As ERAM Byte

Dann wird die Variable von dir (und die fortfolgenden) automatisch angehängt und die ersten beiden Variablen als Dummy (die du natürlich nicht benutzen solltest wenn du probleme hast) deklariert.

Zweite Variante wenn man selbst Hand anlegen will in der Adressvergabe ist die Vergabe als Position:

Dim DeineVar As Byte At &h100

&h100 wäre demnach beispielsweise die hexadezimale Adresse die du vergeben willst (absolut).

Grüße Wolfgang

[Zapo.]

ja, dann ist mir das klar. finde ich halt nicht so elegant gelöst das mit den DUMMYs (aber funktioniert...)

das mit den Adressen find ich eleganter....

danke für deine Antwort!

[Ceos]

ich sags doch >_< wenn man dummys anlegt, und der eeprom während des "einschalten" kompromittiert wird, gehen die ersten 1-3 operationen manchmal in die hose, lieber das starten des µC sicherer machen also solche spielereien wo man den fehler nur kaschiert ...

bei der lösung mit der addresse, möchte ich fast wetten das auch hier die ersten 2 bytes die du anlegst hin und wieder zerstört werden, unabhängig wie tief du sie im eeprom vergräbst!

[BlueNature]

Servus Zapo.,

wenn du sichergehen willst das ein EEPROM-Byte auch wirklich geschrieben wurde, dann gehst du am besten her und machst ein Vergleichslesung. Also Schreibzyklus mit nachhfolgenderm Vergleich der geschriebenen Daten. Dann erst das nächste Byte...

Andernfalls gibt es die Möglichkeit über die internen Flags zu schreiben. Es existiert ei, nenne es einmal "EEPROM-Write-Flag", das im entsprechen Datenblatt deines speziellen AVR's genau beschrieben ist. Das gibt ein OK zurück, sobald der Schreibvorgang wirklich beendet ist. Das kannst du als Interrupt oder als Flag direkt auswerten. Das kommt auf deine Vorlieben an.

Grüße Wolfgang

[PicNick]

Ich hab' in einem anderen Thread die Aussage gefunden, dass die Megas beim booten (reset) manchmal die ersten Byte des ERAM vernichten.
Ich kann es nicht persönlich bestätigen, aber was soll's:
Versuche einfach, einige Bytes vorne frei zu lassen und erst dann deine Werte einzutragen.

Solltes das tatsächlich helfen, dann teile uns das aber bitte mit. Mit so einem Phänomen legt man lange Nächte mit Fehlersuchen hin.

[stefan_Z]

Ja, das Phänomen mit dem ersten genukten Bytes habe ich auch mal gelesen... War irgend ne Seite die Kamera-Funk-Auslöser verkauft...