Hi ich habe ein Problem beim schreiben bzw. beim lesen des EEPROM. Mein Code befindet sich im Anhang. Normalerweise befinden sich mehr Funktionen in dem File ich hab es aber mal zur Darstellung meines Problems zusammengestrichen. Zur beschreibung der Funktion void UI_vTempSoll(void): Wenn keine Taste gedrückt ist soll mein Dregeber ausgewertet werden. Je nachdem um wieviele Schritte er seit der letzten Auswertung nach rechts oder links gedreht wurde, soll sich der wert "Soll" entsprechend ändern. Bis hierhin Funtioniert alles Prima. Wenn die Entertaste gedrückt wird soll der Wert "Soll" in den EEPROM übernommen werden.Danach lese ich den Wert nochmal zurück dies dient aber nur zum debuggen. Nun zu meinem Problem. Ich kann Werte von 0x00-0x07,0x10-17,0x20-0x27 u.s.w. Problemlos schreiben und zurück lesen. Alle werte dazwischen d.h. 0x08-0x0F,0x18-0x1F u.s.w. gehen aber nicht zurück zu lesen. Die Software bleibt einfach in der Leseroutine hängen bzw. sie bekommt einen Reset. Wäre für jeden Tip dankbar. Thx im Voraus.
:
Verschoben durch User
Mir ist gerade aufgefallen das in dem von mir angehefteten Code eine Klammer fehlt die die Funktion void UI_vTempSoll(void)schließt. Die ist im Original aber Vorhanden daran liegts also nicht.
Was hat das mit gcc zu tun? Irgendwie liest keiner mehr die Beschreibungen der einzelnen Subforen hier.
1 | Fragen zu den GNU-Toolchains für AVR-, ARM- und MSP430- |
2 | Mikrocontroller, AVR-GCC, MSPGCC, WinAVR, WinARM, ... |
-> Verschoben
M. Faid schrieb: > Nun zu meinem Problem. > > Ich kann Werte von 0x00-0x07,0x10-17,0x20-0x27 u.s.w. Problemlos > schreiben und zurück lesen. Alle werte dazwischen d.h. > 0x08-0x0F,0x18-0x1F u.s.w. gehen aber nicht zurück zu lesen. Die Gemeinsamkeit besteht hier anscheinend darin, dass Bit 3 gesetzt ist. Der Unterschied zwischen 0x09 und 0x01 besteht nur im gesetzten Bit 3. > Die > Software bleibt einfach in der Leseroutine hängen bzw. sie bekommt einen > Reset. woher weißt du das?
Ich arbeite mit dem AVR-Studio und hab mir einfach nen Breakpoint auf ne Init Funktion gesetzt die noch vor der Hauptschleife aufgerufen wird also im main.c Wenn der besagte fehler auftritt lande ich dann bei diesem Breakpoint. Also bedeutet das für mich das mein Programm neu anläuft -> einen reset bekommt. Mit dem bit 3 hast du recht aber mir erschließt sich die Ursache dafür nicht.
M. Faid schrieb:
> Mein Code befindet sich im Anhang.
Da scheint was verloren gegangen zu sein, ich kann kein main()
entdecken, keine Informationen zum verwendeten Controller, etc, pp.
Dafuer aber noch eine Menge Code, der sich nicht unmittelbar auf das
Problem bezieht.
@Oliver Die version ist die 4.14 optimirung ist ausgeschaltet. @Peter Stegemann Den ganzen code anzuhängen wird zu umfangreich. Ich hänge aber trotzdem nochmal das main.c an und das ui_heater.c das ui_heater.c ist sozusagen das EEPROM.c nur ungeschnitten Benutzt wird ein ATMEGA32 der mit 8MHz läuft.
M. Faid schrieb: > Die version ist die 4.14 Das ist die AVR-Studio-Version. Die WinAVR-Version wird dann aber vermutlich ähnlich alt sein. > optimirung ist ausgeschaltet. WinAVR updaten, oder zumindest die Optimierung einschalten, ansonsten schlägt beim Lesen ein Hardwarebug zu.
M. Faid schrieb:
> Den ganzen code anzuhängen wird zu umfangreich.
Dann musst du ihn reduzieren.
Regel 1 beim Debuggen: Grenze das Problem ein. Und das eben nicht durch
ein rein theoretisches Ausschlussverfahren (oh wie oft habe ich den
Spruch gehoert: "Daran kann es nicht liegen..."), sondern indem du alles
rauswirfst, was keinen Enfluss auf den Fehler haben sollte - bis der
Fehler verschwindet. Oder du naeherst dich von der anderen Seite: Du
baust dir einen Berg von Unit-Tests auf, bis du einen hast, bei dem der
Fehler auftritt.
Was sicher nicht hilft: Bedeutungslose Ausschnitte von Code posten, die
so nie gelaufen sind und damit andere Leute beschaeftigen.
@Peter Stegemann Der code ist so gelaufen bis ich die EEPROM Funktionen implementiert habe. wenn ich sie raus nehme läuft der Code auch wieder. Ich habe es extra vermieden großartig viel Code zu Posten aber du hast ja danach gefragt. Der Fehler ist auf die von mir zuerstgepostete Funktion breits eingegrenzt. Ich würde mich hier nicht melden wenn ich nicht schon versucht hätte das Problem selbst zu finden!
>Ich würde mich hier nicht melden wenn ich nicht schon versucht hätte das >Problem selbst zu finden! Lesen: Stefan Ernst schrieb: >WinAVR updaten, oder zumindest die Optimierung einschalten, ansonsten >schlägt beim Lesen ein Hardwarebug zu. Einige ältere Versionen der eeprom-Funktionen umschiffen eine Hardwarebug der Megas nicht richtig, was dann zum reset führt. Also: >WinAVR updaten, oder zumindest die Optimierung einschalten, ansonsten >schlägt beim Lesen ein Hardwarebug zu. Oliver
M. Faid schrieb: > @Peter Stegemann > Ich habe es extra vermieden großartig viel Code zu Posten aber du hast > ja danach gefragt. Ich habe nicht nach viel Code gefragt, sondern nach einem lauffaehigen Exemplar, das den von dir genannten Fehler zeigt. > Ich würde mich hier nicht melden wenn ich nicht schon versucht hätte das > Problem selbst zu finden! Dann solltest du auch Rat annehmen.
@Peter Stegemann. Ich bin schon so vorgegangen wie du es beschrieben hast. Hab alles rausgeschmissen was nicht notwendig ist...der Fehler bleibt aber bestehen. Der Restet tritt immer wie oben beschrieben auf...immer wärend des lesens aber nur dann wenn das dritte bit bei dem zu lesenden wert gesetzt ist. Nur wusste/weiß ich halt nicht warum der Fehler auftritt. Ich bin dir natürlich dankbar für deine Tips! Aber sollte es wirklich ein Hardwarebug sein dann kann ich vermutlich lange suchen. Werd mir jetzt mal ne aktuelle version holen und schauen ob der fehler dann behoben ist.
Vielen Dank nochmal an alle! Es lag tatsächlich an der veralteten WINAVR Version. Mfg Faid
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.