ATmega128, EEProm

Stefan Brröring schrieb:

Früher hatten Atmel MCUs das Problem, dass das erste Byte (Adresse 0) im EEPROM manchmal überschrieben wurde. Beim mega128 steht dieser Fehler allerdings nicht in den Errata.

Christian

--
Christian Zietz  -  CHZ-Soft  -  czietz (at) gmx.net
WWW: http://www.chzsoft.de/
PGP/GnuPG-Key-ID: 0x6DA025CA

Hallo,

Am 25.05.2011 09:50, schrieb Stefan Brröring:

Wozu soll den das gut sein?

Das erscheint mir nicht sehr plausibel.... Ich denke es ist eher sowas wie BOD Fuse nicht gesetzt oder so. ALso eher eine Hardwaresache

Wenn noch Platz im EEPROM ist, dann würde ich das mehrfach ablegen, und über die Bytes im Speicher eine Checksumme ziehen.

Andreas

Stefan Brröring schrieb:

Achso, den Abschnitt "Preventing EEPROM Corruption" im Datenblatt kennst Du sicher schon?

Christian

--
Christian Zietz  -  CHZ-Soft  -  czietz (at) gmx.net
WWW: http://www.chzsoft.de/
PGP/GnuPG-Key-ID: 0x6DA025CA

Und wenn man?s gleich richtig machen will, betreibt man Kundenbindung durch hohe Qualität und nicht durch Zwangsmaßnahmen. Das hält dann auch langfristig und ist nicht von _einer_ Hardware abhängig...

SCNR, Paul

...

Klassische Ursache ist das unbeabsichtigte Auslösen von Schreib- zugriffen aufs EEPROM, während die Betriebsspannung gerade zu- oder abgeschaltet wird. Die ebenso klassische Lösung heißt Brownout- Detektor.

Andererseits ist es nur fair, wenn euch solches Kopierschutz/ Lizenzgedöhns nun selber auf die Füße fällt.

XL

Bei 66,7% Ausfallquote sagst du, es funktioniert soweit alles? Naja...

Wenn wirklich Datenmüll auf der Schnittstelle verantwortlich ist, wäre der Ausweg natürlich vor allem eine stärkere Prüfsumme. Bei nur 8 Bit stimmt die Prüfsumme in einem von 256 Fällen, selbst wenn sie garnicht berechnet wird, sondern aus einem Zufallsgenerator stammt, das muß man sich einfach mal klarmachen. Ich würde also unabhängig davon, was die wirkliche Ursache der Probleme ist, an dieser Stelle wenigstens eine CRC16-Prüfsumme einsetzen und dies nicht nur beim Schreiben der Seriennummer, sondern auch beim Lesen, denn es nützt nichts, einen unzuverlässigen Kanal nur in einer Richtung abzusichern. Und, wenn sie schonmal da ist, würde ich sie auch gleich mit im EEPROM speichern, dann schützt sie die Daten auch dort.

Das ist die eigentlich spannende Frage. Ich glaube nämlich nicht wirklich an die Theorie mit dem zufälligen Datenmüll auf der Schnittstelle. Der vorhandene Schutz ist zwar deutlich schwächer, als er sein könnte, aber wiederum auch nicht so schwach, daß er für eine Ausfallquote von 66% verantwortlich sein kann. Dazu müßten die betroffenenen Kunden die Schnittstelle schon ziemlich lange absichtlich mit Zufallszahlenfolgen bombardieren, denn die Wahrscheinlichkeit für ein zufällig gültiges Paket liegt beim angegeben Datenformat bei 1:2^40. Eher wahrscheinlich wäre da schon ein gezielter Angriff. Das Datenformat stellt ja nun nicht wirklich eine Herausforderung für's reverse engineering dar und der unbekannte Prüfsummenalgorithmus läßt sich, wie weiter oben schon gesagt, durch brute force mit maximal nur 2^8 Versuchen überwinden.

Interessant zur Fehlersuche wäre mal gewesen, was eigentlich anstatt der korrekten Seriennummer im EEPROM stand. Aber bei der hohen Ausfallquote sollte es ja ein leichtes sein, das beim nächsten Auftreten des Problems mal zu ermitteln. Mit dem Wissen kann man dann vielleicht eine andere Theorie bezüglich der Fehlerursache aufstellen.

Ich sehe da auf jeden Fall vier grundsätzliche Möglichkeiten:

1) Programmfehler, die den EEPROM-Inhalt korrumpieren 2) EEPROM-Korruption durch Nichtbeachtung der der Auswirkungen der "shared" Hardware für das Schreiben von EEPROM und Flash. 3) Unbeabsichtigte EEPROM-Löschung durch nicht gesetzte EESAVE-Fuse. 4) Bewußter Angriff durch den Kunden.

Ist mir klar. Ich versuche auch Dongle und ähnliches zu vermeiden.

Aber in dem Fall geht es aber um ein System, was wir in Serie bauen und das im Bereich Landwirtschaft verkauft wird. Und Landwirte sind offenbar überall auf der Welt gleich. Deshalb hatten wir bei der alten Version gelegentlich Probleme, den Kunden klar zu machen, dass sie, wenn sie mehrere Geräte kaufen für jedes Gerät auch eine Softwarelizenz kaufen müssen.

Deshalb sind wir bei der neuen Gerätegeneration dazu übergegangen, die Geräteseriennummer abzufragen.

Gruß

Stefan DF9BI

Am 25.05.2011 10:41, schrieb Christian Zietz:

War mir im Prinzip schon bekannt, BOD ist natürlich ein guter Tipp. Wobei der Schreibvorgang normalerweise nicht beim Kunden vorkommt, d.h. wir setzen die Seriennummer, dazu wird ins EEProm geschrieben und beim Kunden wird (normalerweise) nur noch gelesen.

Es werden auch sonst keine Daten im EEProm abgelegt. Deshalb ist dein erster Tipp mit dem Byte an Adresse 0 ist auch nicht ganz abwegig. Die Seriennummer steht tatsächlich als einziges im EEProm und würde wohl bei Überschreiben von Byte 0 beschädigt werden. Ich speichere die Seriennummer allerdings mit 5 Bytes ab und es waren mehrere Bytes verändert.

Wie schon geschrieben: Das Problem ist bisher nur bei Kunden beobachtet worden und konnte von uns bisher hier nicht reproduziert werden.

Gruß

Stefan DF9BI

Hallo Stefan

Warum erlaubst du überhaupt, dass die Seriennummer vom PC aus geschrieben wird? Ich würde das direkt per Programmer schreiben, und zwar möglichst ins Flash und nicht ins EEPROM, schließlich ändert sich die Seriennummer normalerweise nicht mehr.

Und dank Google und Co. kann das jetzt weltweit jeder Kunde nachlesen. ;)

Gruß Thorsten

--
PGP welcome!
Thorsten online: http://www.ostermann-net.de/electronic
Rund um Schrittmotor, Fräs-Bohr-Plotter & Mikrocontroller

Hallo Stefan!

Da würde ich eher die Hardware teurer machen und die Software frei verfügbar machen. Oder hat die alleine auch einen Nutzwert?

Gruß Thorsten

--
PGP welcome!
Thorsten online: http://www.ostermann-net.de/electronic
Rund um Schrittmotor, Fräs-Bohr-Plotter & Mikrocontroller

Unter bestimmten Umständen wird also doch geschrieben. Also aufpassen daß das nicht im Brownout passieren kann, und auch keine Interrupts auftreten können, oder besser abgearbeitet werden. Dabei fällt mir ein daß ich für ein Hobbyprojekt einen Datensatz zweimal abspeichere. Gelegentlich kommt es vor daß beim wiedereinlesen der Satz kaputt ist, feststellbar über die Checksumme. Dann lese ich den 2. Satz ein, bisher trat der Fall von 2 kaputten Sätzen nicht auf.

Paul

Bau doch einfach eine DALLAS one wire Seriennummer ein. Rest wie gehabt. Ich habs damals mit TO92 Gehäuse bekommen, lässt sich mit einem 8031 bidi portpin praktisch ohne zusätzliche HW einlesen. Bei anderen CPUs brauchste evtl. noch einen pull-up.

Ansonsten hab ich mit diversen uC (ADuC 812 besomders, silabs F3xx) u.a. (irre) Probleme mit den internen EEproms gehabt. Seitdem ich überall externe Reset Bausteine angebaut habe, ist das Problem Geschichte. Seitdem nie wieder zerschossene EEprom Daten. Und was hab ich für einen Aufwand getrieben:

2 wechselnde Datenblöcke mit CRC gesichert, die wildesten IR Service Routinen, Sicherungsbits konnte ich leider nicht benutzen, da user Parameter mit abgespeichert wurden...

Saludos Wolfgang

--
Meine 7 Sinne:
Unsinn, Schwachsinn, Blödsinn, Wahnsinn, Stumpfsinn, Irrsinn, Lötzinn.
Wolfgang Allinger   Paraguay             reply Adresse gesetzt !
ca. 15h00..21h00 MEZ  SKYPE:wolfgang.allinger

Am 25.05.2011 14:35, schrieb Thorsten Ostermann:

Nein, aber wir bauen das Vorgängersystem seit ca. 1993. Seitdem gab es einige Softwareupdates, z.B. von Dos auf Windows, aktuell von Windows-XP auf Windows-7.

Die Geräte sind teilweise seit 1993 in Betrieb und funktionieren nach wie vor einwandfrei. Reparaturen gibt es praktisch nur wegen Vandalismus. Wenn dann ein Kunde auf Windows-7 umstellen will (warum auch immer), muss er dafür eben zahlen.

Wir haben von Anfang an eine verschlüsselte Lizenz-Datei dabei. Darin ist der Name und die Adresse des Kunden gespeichert. Diese Angaben erscheinen dann auf verschiedenen Ausdrucken.

Problem dabei ist, dass einige unserer ausländischen Vertriebspartner eigene Programmversionen als Muster mit deren Name im Ausdruck haben. Wir haben den Verdacht, dass die diese Programmversion an die Endkunden weitergeben. Mit einer Seriennummerabfrage ist das Problem dann vom Tisch, bzw. dann erledigt sich der Verdacht.

Gruß

Stefan DF9BI

Nein, es wird normalerweise nicht geschrieben, nur bei uns in der Werkstatt. Aber wenn die Seriennummer zerstört ist, helfen wir dem Kunden telefonisch weiter. Dabei wird dann eben die Seriennummer neu geschrieben. Das ist aber ein Fall, der eben nicht auftreten sollte.

Ich habe andere Systeme, wo ich deutlich größere Datenmengen ins EEProm schreibe, auch im Normalbetrieb beim Kunden, und wo das Problem bisher bei >100 Installationen nicht aufgetaucht oder zumindest nicht aufgefallen ist.

Gruß

Stefan DF9BI

Am 25.05.2011 14:34, schrieb Thorsten Ostermann:

Ich will gerade eben nicht, dass für jedes Kundengerät eine neue Version compiliert wird.

Ich habe das inzwischen geändert ;-)

Gruß

Stefan DF9BI

nd

=C3=A4ndert

Musst Du doch nicht. Du wirst ja nach dem Kompilieren sowieso das ELF in ein Motorola oder Intel HEX dumpen. Dieser Vorgang kann seinen Input nicht nur aus einer Datei beziehen, sonderen aus beliebig vielen Quelldateien. Nichts ist einfacher als ein kleines Skript zu bauen, dass on the fly ein ELF oder was =C3=A4hnliches generiert, oder man =C3=A4n= dert die betreffenden Bytes in dem HEX direkt ab.

Wolfgang

Das Problem ist dass der AVR amok läuft wenn die Spannung einbricht. BOD is pflicht falls man das eeprom nutzt. Ausserdem kann man der Schreibfunktion eine "magic" variable übergeben die nur unmittelbar vor einem absichtlichen Schreiben gesetzt wird. Wenn dann der Stack kracht ist die Fehlerwarscheinlichkeit geringer.

Hast du schon geprüft was genau verändert wird?

--
MFG Gernot

Wir würdest _Du_ den Kunden zu Ehrlichkeit erziehen? _Wir_ finde es jedenfalls nicht so lustig, wenn ein Kunde eine Zukaufoption einmal kauft und auf seinen Park aus 30 Geräten munter draufkopiert.

-ras

--

Ralph A. Schmid

http://www.dk5ras.de/ http://www.db0fue.de/
http://www.bclog.de/

Wenn man aber nun mal seine Lizenzen pro Gerät verkauft, dann ist sowas notwendig, will man nicht vom Kunden betrogen werden. Man hat nix gekonnt und muß trotz guter Software zusperren, wenn das Zeug nur noch kopiert wird.

-ras

--

Ralph A. Schmid

http://www.dk5ras.de/ http://www.db0fue.de/
http://www.bclog.de/