Hallo zusammen Mein ATTiny13 verliert oder verändert seine EEPROM Daten wenn ich mit Steckern hantiere die an den PORTB Pins angeschlossen sind. Dasselbe passiert wenn ich z.B: mit Akku-Speisung hantiere (z.B: Stromversorgung mittels 12S über DC-DC Wandler nach 5V, das funkt jeweils beim einstecken). Im EEPROM habe ich nur 2 Bytes abgelegt, typische Datenwerte sind FE und 02. Die sind so auch nachvollziehbar vorhanden, und der Code arbeitet mit diesen Daten. Wenn ich aber mit den besagten Steckern hantiere, kann es manchmal passieren dass nur noch 1 Byte mit 00 im EEPROIM steht, oder einer der beiden Bytes (üblicherweise das 1.) sich auf einen beliebigen Wert verändert. Nach Studium der Threads zum Thema habe ich folgende Massnahmen durchgeführt: 1. Brown-Out Detection aktiviert und auf 4.3V gesetzt. 2. Fuse EESAVE gesetzt. 3. Register EEPROM Master Write Enable nach dem Schreibvorgang wieder gelöscht. 4. Im Code dafür gesorgt, dass die Schreibinstruktionen ausschliesslich nur beim Booten stattfinden, und nur wenn ein Taster beim PowerUp für 3s gedrückt ist. Wenn der Taster nicht gedrückt ist, kommt die Sequenz schon gar nicht in den Schreibmodus sondern springt ins zyklische Programm. Es muss fast mit EMV und Hardware und Power udgl. zu tun haben. Vom Code her schliesse ich es fast aus. Komisch finde ich auch dass das Flash nicht betroffen ist. Anscheinend ist das EEPROM heikler (falls es denn EMV udgl. ist). Oder hat noch jemand eine Idee? Danke lg Fredi
Fredi W. schrieb: > Wenn der Taster nicht gedrückt ist, kommt die Sequenz > schon gar nicht in den Schreibmodus Sicher? Lösch doch einfach mal den EEPROM-Schreibcode, ob dann der Fehler immer noch auftritt. Ich hab bezüglich Taster entprellen schon die verrücktesten "nicht Lösungen" gesehen.
Fredi W. schrieb: > Vom Code > her Und der sieht wie aus? ciao gustav Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang z.b. Test.asm
Es gab bei den AVRs mal ein Problem mit dem EEPROM Byte an Adresse 0, und zwar mit genau dem beschriebenen Symptom. Ob das bei den neuesten Typen/Revisionen immer noch so ist, weiß ich nicht, aber ich würde vorsichtshalber diese Adresse meiden.
> Massnahmen durchgeführt: > ... > 2. Fuse EESAVE gesetzt. Was hat dies mit dem beschriebenen Problem zu tun? Aus dem Datenblatt: EESAVE Preserve EEPROM memory through Chip Erase
:
Bearbeitet durch User
Dass Eeprom braucht eine stabile Stromversorgung auch bei read-only Zugriffen.
Stefan F. schrieb: > Dass Eeprom braucht eine stabile Stromversorgung auch bei read-only > Zugriffen. Sehr richtig. Dehalb sollte man mal auf den/die üblichen (vielleicht nicht vorhandenen?) Abblock-Kondensatoren hinweisen. Auch weitere Entstör-Massnahmen für die Versorgungsspannung sollten/könnten helfen Probleme zu vermeiden.
Stefan F. schrieb: > Dass Eeprom braucht eine stabile Stromversorgung auch bei read-only > Zugriffen. Nicht nur das EEprom, sondern auch die CPU. Bei schlechter Versorgung kann sie Befehle falsch ausführen und dann nützen Betrachtungen des Codes null Komma nichts: Die CPU macht ja dann gar nicht das, was der Code ihr sagt.
Peter D. schrieb: > Fredi W. schrieb: >> Wenn der Taster nicht gedrückt ist, kommt die Sequenz >> schon gar nicht in den Schreibmodus > > Sicher? > Lösch doch einfach mal den EEPROM-Schreibcode, ob dann der Fehler immer > noch auftritt. Ich hab bezüglich Taster entprellen schon die > verrücktesten "nicht Lösungen" gesehen. Peter D. schrieb: > Lösch doch einfach mal den EEPROM-Schreibcode, ob dann der Fehler immer > noch auftritt. Ich hab bezüglich Taster entprellen schon die > verrücktesten "nicht Lösungen" gesehen. Danke Peter für deine gute Idee. Ich habe nun die komplette EEPROM Schreibsequenz im Code ausgeklammert (deaktiviert und getestet dass es deaktiviert ist), dennoch verändern sich die EEPROM Daten wenn ich mit dem PINB Stecker hantiere. Also vom Code her kann ich es jetzt erst recht faktisch ausschliessen. Ich prüfe jetzt noch die anderen Antworten, dort wird u.A. "Power Supply Instabilität" erwähnt, das schaue ich mir näher an. Danke und lieben Gruss Fredi
Andreas B. schrieb: > Es gab bei den AVRs mal ein Problem mit dem EEPROM Byte an Adresse 0, > und zwar mit genau dem beschriebenen Symptom. Ob das bei den neuesten > Typen/Revisionen immer noch so ist, weiß ich nicht, aber ich würde > vorsichtshalber diese Adresse meiden. Danke Andreas für diesen Hinweis. Bei mir ändert oder löscht es aber teils auch die Daten an Adresse 01 und nicht nur an Adresse 00. Von da her würde das Meiden der Adresse 00 nichts helfen. Danke trotzdem und lieben Gruss Fredi
S. L. schrieb: > Was hat dies mit dem beschriebenen Problem zu tun? > Aus dem Datenblatt: EESAVE Preserve EEPROM memory through Chip Erase Hallo ja da hast du Recht und das ist laut Datenblatt eigentlich nicht relevant. Aber ich dachte ich bringe den Punkt ebenfalls aufs Tapet weil es eben mit dem EEPROM zusammenhängt. Aber ich denke eigentlich auch wie du, dass dieses Fuse nichts beiträgt für meine Problemlösung. Lieben Gruss Fredi
Wie sind denn die Pins beschaltet? Häng doch mal 1n pauschal an jeden Pin an dem du "rumhantierst", das wirkt oft schon Wunder
Fredi W. schrieb: > Danke Andreas für diesen Hinweis. Bei mir ändert oder löscht es aber > teils auch die Daten an Adresse 01 und nicht nur an Adresse 00. Von da > her würde das Meiden der Adresse 00 nichts helfen. Und du bist dir absolut sicher, daß brown out aktiviert ist? Oliver
Fredi W. schrieb: > dennoch verändern sich die EEPROM Daten wenn ich mit > dem PINB Stecker hantiere. Wo geht denn dieser Stecker hin? Hohe Ströme von der Batterie dürfen keinen niederohmigen Pfad zu den Eingängen sehen. Eingänge kann man gut mit Widerständen schützen (10k..100k), Ausgänge oft auch (100R..1k). 44V und Funken, das klingt nicht gut. Die Funken kannst Du mit einem Vorwiderstand zur Strombegrenzung vermindern.
Peter D. schrieb: > 44V und Funken, das klingt nicht gut. Die Funken kannst Du mit einem > Vorwiderstand zur Strombegrenzung vermindern. Absolut! Ein 10 Ohm sollte hier schon genügen, der DC/DC dahinter sollte damit keine Probleme haben
Stefan F. schrieb: > Dass Eeprom braucht eine stabile Stromversorgung auch bei read-only > Zugriffen. Ich vermute hier habe ich das Problem. Ich untersuche das jetzt näher. Danke für den Hinweis und Gruss Fredi
Wastl schrieb: > Sehr richtig. Dehalb sollte man mal auf den/die üblichen > (vielleicht nicht vorhandenen?) Abblock-Kondensatoren hinweisen. > Auch weitere Entstör-Massnahmen für die Versorgungsspannung > sollten/könnten helfen Probleme zu vermeiden. Ui ui.... mir dämmert etwas. Ich habe evt. ein Power Supply Problem. Mehr dazu weiter unten. Danke und lieben Gruss Fredi
Angehängte Dateien:
-
IMG_2647.JPG
200 KB
Hier noch die Schaltung, der besagte Stecker ist beim Ausgang PINB 0 (IC Pin 5). Ich bin dem Problem auf der Spur, die Z-Diode ist glaub keine gute Idee.
Ich würde den +/- Anchlüssen mal n 100µ Elko parallel hängen, den 50n(?!) gegen 100n Keramik ersetzen und dazu parallel n 10µF Elko, so wirkt das recht schwachbrüstig entstört wie es ist, gerade wenn n DC/DC im Spiel ist ;)
Fredi W. schrieb: > Hier noch die Schaltung, der besagte Stecker ist beim Ausgang PINB 0 (IC > Pin 5). Ich bin dem Problem auf der Spur, die Z-Diode ist glaub keine > gute Idee. Ganz ehrlich, so eine Schaltung habe ich noch nie gesehen! Entweder direkt 5V (oder 3.3V) ab dem DC/DC Wandler, oder wenn es dann ganz genau sein soll (ist aber eher für analoge Schaltungen) einen LDO nach dem DC/DC noch verwenden. Dein IL wird ziemlich sicher auch nicht konstant 40mA sein, da der Tiny je nach verwendeter Peripherie, aktiven Output-Pins plus dein Beigemüse an Komponenten schwanken wird. -> Du hast ein Speisungsproblem!
Andreas B. schrieb: > Es gab bei den AVRs mal ein Problem mit dem EEPROM Byte an Adresse 0, > und zwar mit genau dem beschriebenen Symptom. Ob das bei den neuesten > Typen/Revisionen immer noch so ist, weiß ich nicht, aber ich würde > vorsichtshalber diese Adresse meiden. Dieses uralte Problem war bei den ersten AVR. Bei denen wurde bei einem Powerfail im ungüngtigen Fall evtl. die Ladungspumpe zum Löschen der EEPROM-Zelle eingeschaltet. Gleichzeitig wurde aber die EEPROM-Adresse durch die fallende Betriebsspannung von der vorher eingestellten Adresse auf 0 gesetzt (klar: bei 0V ist die Adresse auch 0). Und so wurden alle zwischendurch angetroffenen EEPROM-Zellen kurz ein wenig "angelöscht". Am meisten traf es dann aber die Speicherstelle 0, die nach ein paar Powerfails irgendwann korrumpiert oder gelöscht wurde. Allerdings is der gelöschte Zustand eines EEPROM-Zelle eben die 1, womit die Adresse 0 dann den Wert xff enthielt. Bei den Neuen AVR ist das mit dem Aktivieren des Brown-Out behoben, denn der schaltet die LAdungspumpe dann auf jeden Fall ab. Fredi W. schrieb: > Bei mir ändert oder löscht es aber teils auch die Daten an Adresse 01 > und nicht nur an Adresse 00. Ich würde hier zuallererst mal für eine bombensichere und gut geblockte Versorgung sorgen. Fredi W. schrieb: > Dasselbe passiert wenn ich z.B: mit Akku-Speisung hantiere (z.B: > Stromversorgung mittels 12S über DC-DC Wandler nach 5V, das funkt > jeweils beim einstecken). Steckst du da nur die Versorgung ab, lässt aber den Port insgesamt beschaltet? Oder andersrum: kann es sein, dass du da irgendwas mit parasitärer Versorgung zusammenbastelst. Also, dass an den Portpins (gern auch über ein Poti oder Widerstände) noch Spannung anliegt, während Vcc ausgesteckt ist?
Ein LDO wurde Dir ja schon empfohlen. Vorschlag: MCP1824(T)-5002 https://ww1.microchip.com/downloads/aemDocuments/documents/APID/ProductDocuments/DataSheets/MCP1824-Data-Sheet-DS20002070.pdf Der hat nämlich einen Power-Good Ausgang, der signalisiert, wann die Ausgangsspannung stabil ist. Diesen Ausgang verbindest Du mit dem Reset-Pin des AVR (Pin1) (Pull-Up nicht vergessen), und dadurch wird dieser solange im Reset gehalten, bis sich alles eingeschwungen hat. Das sollte helfen, egal ob Du Brownout aktiviert hast oder nicht. fchk
Andreas B. schrieb: > Es gab bei den AVRs mal ein Problem mit dem EEPROM Byte an Adresse 0, > und zwar mit genau dem beschriebenen Symptom. Ob das bei den neuesten > Typen/Revisionen immer noch so ist, weiß ich nicht, aber ich würde > vorsichtshalber diese Adresse meiden. Dieses Problem ist gefühlt Jahrhunderte her, das war mal so in den frühen 2000er Jahren. Wirst du auf keinem der heute gekauften AVR8 mehr antreffen. Wenn heute solche Problem auftreten, liegt es immer an lausiger Versorgung. Oder halt daran, dass der BOD nicht aktiviert ist.
Patrick B. schrieb: > Entweder direkt 5V (oder 3.3V) ab dem DC/DC Wandler, oder wenn es dann > ganz genau sein soll (ist aber eher für analoge Schaltungen) einen LDO > nach dem DC/DC noch verwenden. Dazu kommt dass dieses kleine Konstrukt offensichtlich im RC-Bereich eingesetzt wird. Wenn an der Schaltung z.B. ein Modellbau-Servo betrieben wird zieht es die Versorgungsspannung gehörig nach unten.
Fredi W. schrieb: > die Z-Diode ist glaub keine gute Idee. Patrick B. schrieb: > Dein IL wird ziemlich sicher auch nicht konstant 40mA sein, Nehme dir mal das Datenblatt von deiner Z-Diode und rechne anch welsche Spannung dort anliegt, wenn dein µC mal 0mA, 40mA und 100mA (höhere Peeks sollte so kurz sein das der Abblockkondensator diese abfangen kann) benötigt. Die 40mA sind nur ein Pi mal Daumen Durschnittswert als Anhaltspunkt und nicht der Momentanbedarf. Wenn du es genauer wissen willst, einfach mal mit einem Oszi die Spannung über deinem Vorwiderstand anzeigen lassen.
Frank K. schrieb: > Vorschlag: MCP1824(T)-5002 Vielleicht lieber einen MCP1754T, denn der Eingangsspannungsbereich des MCP1824 ist doch arg eng (nur bis 6 V) und der DC-DC vermutlich ungeregelt.
Ich muß mich korrigieren: Der DC-DC-Konverter des Eröffners ist geregelt, da weiter Eingangsbereich.
Patrick B. schrieb: > Du hast ein Speisungsproblem! Ja das ist nun definitiv bestätigt! Ich habe jetzt gerade keinen LDO mit Dropout < 1.0V zur Hand, aber ich habe festgestellt dass bei meinem Z-Dioden "Spannungsregler" der 12 Ohm Vorwiderstand doch noch zu gross bemessen war, wie auch der Blockkondensator mit 50n zu klein bemessen war. Ich habe den Vorwiderstand auf 6 Ohm halbiert, und den Blockkondensator auf 330n erhöht. Nun konnte ich den Fehler nicht mehr nachstellen. Hinzu kommt der Umstand, dass das angeschlossene Test-Servo ziemlich viel Strom verbraucht, weshalb die Situation der unstabilen Versorgung das Problem erst recht verstärkt hatte. Später wird ein ESC angehängt, der verbraucht dann deutlich weniger Strom und hat keine variable Lastabhängigkeit. Aber mit dem lastfreien Test-Servo muss es natürlich auch gehen. Dann noch der obige Vorschlag des Anti-Blitzschutz beim Akkustecker einbauen, und dann denke ich sollte es gut sein für die Ewigkeit. Danke allen Beteiligten für die tolle Hilfe. Ich hätte nicht gedacht dass labile Versorgung zu EEPROM Datenproblemen führen können. Grundsätzlich finde ich diesen Umstand tragisch, insbesondere wenn der Code im Flash vom Problem nicht betroffen ist und das Programm munter mit den zufällig veränderten Daten weiterarbeitet... Lieben Gruss an alle Fredi
:
Bearbeitet durch User
Fredi W. schrieb: > Mein ATTiny13 verliert oder verändert seine EEPROM Daten wenn ich mit > Steckern hantiere die an den PORTB Pins angeschlossen sind. Dasselbe > passiert wenn ich z.B: mit Akku-Speisung hantiere (z.B: Stromversorgung > mittels 12S über DC-DC Wandler nach 5V, das funkt jeweils beim > einstecken). 1.) Hör auf zu hantieren. 2.) Stromversorgung ist irgendwas zwischen Spannungsteiler und GND nicht angeschlossen.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.