EEPROM SPI liefert falsche Werte

Bbbbb OP #7344070
Lesenswert?
• ▲
▼

Hallo,

Ich bin gerade dabei mit einem Mikrocontroller via SPI einen EEPROM zu beschreiben. Genauer gesagt handelt es sich hierbei um den M95010 EEPROM.

Die Kommunikation mit dem EEPROM scheint reibungslos zu verlaufen, da ich auf meine Fragen stets eine Antwort bekomme. Was mich nun verwirrt ist, dass wenn ich an die Adresse 01 einen schreibbefehl sende mit dem Inhalt 00 und diese anschließend auslese, erhalte ich 0x80. Besagtes Beispiel habe ich im Anhang hinzugefügt.

Erklärung:

  1. Byte = Commandbyte (0x02 = Schreiben, 0x03 = Lesen)
  2. Byte = Adressbyte
  3. Byte = Databyte

Mein Mikrocontroller führt Schreibbefehle aus die Sowohl das Databyte als auch die Adresse jeweils um ein erhöhen. Daraus entstehen die folgenden Werte an Adressen:

Adresse Schreibwert Lesewert

0x01.........0x00.........0x80

0x02.........0x01.........0x81

0x03.........0x02.........0x82

................................

0x79.........0x7E.........0xFD

0x80.........0x7F.........0xFE

0x81.........0x80.........0x7F

0x82.........0x81.........0x80

................................

DATA FF wird nie geschrieben + Read DATA wiederholt sich ab 0x80

Ich verstehe nicht so ganz wie dieses Problem zu Stande kommt, da es so scheint als wäre das highest value Bit immer gesetzt aber dann kommt der Ausnahmefall bei Adresse 0x81 wo auf einmal ein Wert von 7F gelesen wird...

Falls benötigt kann ich auch Teile meines Codes zeigen, aber da der Schreibwert korrekt funktioniert und der M95010 icht programmierbar ist, sollte das keine mögiche Fehlerquelle sein.

Angehängte Dateien:
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
eeprom writer Gast #7344136
Lesenswert?
• ▲
▼

Paul Ö. schrieb:

@EAF könntest du das etwas näher erläutern?

Bin zwar nicht gefragt worden, antworte aber trotzdem.

Nach dem Schreiben tut man (sinngemäss) das hier:

1
 
  do  /*  Check EEPROM Busy bit  */

2
 
  {

3
 
    SPI_WriteByte (EEPROM_READ_STATUS);

4
 
    eep_stat = SPI_ReadByte ();

5
 
  }  while (eep_stat & 0x01);

Und Page Boundaries sind zu beachten, wie EAF schon schrub.

Antwort Zitieren Bearbeiten Löschen Beitrag melden
EAF Gast #7344146
Lesenswert?
• ▲
▼

Paul Ö. schrieb:

@EAF könntest du das etwas näher erläutern?

Ich versuche es.....

Paul Ö. schrieb:

Falls benötigt ..... sollte das keine mögiche Fehlerquelle sein.

Diese Einschätzung....

Angenommen, deine diagnostischen Fähigkeiten wären soweit ausgebildet, dass diese Einschätzung berechtigt ist, dann würdest du diese Frage hier im Forum wohl nicht stellen müssen, sondern könntest das Problem alleine lösen.

Das treibt mich zu dem logischen Schluss, dass der Fehler genau in dem steckt, was ausgeblendet wird. Ist nicht zu 100% sicher, aber doch recht wahrscheinlich.

EAF schrieb:

Mein Glaskugel sagt: Du ignorierst die Pagegrenzen und die Wartezeiten.

Tipp: Wenn es solche Dinge gibt, sollten sie im Datenblatt erwähnt werden. Da (so ich vermute) dir das unbekannt ist, solltest du das nachholen. Ins besondere dein "fehlerfreies" Schreiben daraufhin kontrollieren.

Antwort Zitieren Bearbeiten Löschen Beitrag melden
Bbbbb OP #7344152
Lesenswert?
• ▲
▼

Ich führe diesen Code nach jedem geschriebenen Byte aus, also sollte der EEPROM idR immer aufnahmefähig sein.

1
 
  temp = eepromReadStatus(csPin);

2
 
  while(temp == 0xFB)

3
 
  {

4
 
    temp = eepromReadStatus(csPin);

5
 
  };

mit den Pagesizes hab ich mich noch nicht groß beschäftigt da werde ich dann gleich mal rein schauen.

Antwort Zitieren Bearbeiten Löschen Beitrag melden
eeprom writer Gast #7344192
Lesenswert?
• ▲
▼

Paul Ö. schrieb:

mit den Pagesizes hab ich mich noch nicht groß beschäftigt

Man macht einmal Write enable, dann schreibt man soviel man braucht bis eine Page-Grenze erreicht ist, dann prüft man das Write-in-progress-Bit bis es gelöscht ist und fängt von vorne an. Innerhalb einer Page musst du nicht dauernd Write enable ausführen, du kannst maximal eine Page mit voller Geschwindigkeit und ohne Handshake schreiben.

Deine delay-Routine kommt mir sehr verdächtig vor .... Da gibt es vom Arduino-Framework Besseres.

Antwort Zitieren Bearbeiten Löschen Beitrag melden
A. B. Gast #7344222
Lesenswert?
• ▲
▼

Was für einen Sinn soll "while(temp == 0xFB)" machen? Es geht doch NUR um das WIP Bit, also fragt man ab, ob (temp & 0x1) wahr oder falsch ist. Am Ende der Schreiboperation werden WIP und WEL automatisch zurückgesetzt, aber ob das gleichzeitig passiert bzw. in welcher Reihenfolge ist nicht spezifiziert. Außerdem sind BP1 und BP0 da irrelvant.

Auch die erste Schleife mit "while(temp == 0xF8)" macht keinen Sinn. Entweder ist WEL sofort nach dem Write Enable gesetzt, oder irgendetwas ist schief gelaufen, dann aber weiteres Warten und erneute Statusabfrage sinnlos.

Antwort Zitieren Bearbeiten Löschen Beitrag melden
Bbbbb OP #7347058
Lesenswert?
• ▲
▼

eeprom writer schrieb:

Man macht einmal Write enable, dann schreibt man soviel man braucht bis eine Page-Grenze erreicht ist, dann prüft man das Write-in-progress-Bit bis es gelöscht ist und fängt von vorne an.

Ja gut, aber da ich bei jedem Schreibzyklus als erstes Write enable schreibe, sollte ich dieses Problem was ich durch page sizes bekommen könnte umgehen oder verstehe ich da etwas falsch? Klar diese Prozedur kostet Geschwindgkeit aber diese muss ich momentan eh Künstlich drosseln um meinen logic analyser zu nutzen.

die delay-Routine wird ausschließlich zur Takt-Synchronisierung verwendet dafür ist es eben wichtig, dass es recht genau ist.

Antwort Zitieren Bearbeiten Löschen Beitrag melden
mitlesa Gast #7347094
Lesenswert?
• ▲
▼

Paul Ö. schrieb:

aber dann kommt der Ausnahmefall bei Adresse 0x81 wo auf einmal ein Wert von 7F gelesen wird...

Zeige mal deine Schaltung und Aufbau. Da wird wohl noch ein Problemchen versteckt sein. Ein Fehlender Abblock-Kondensator könnte zu solchen "statistischen" zufälligen Fehlern führen.

Antwort Zitieren Bearbeiten Löschen Beitrag melden
A. B. Gast #7347104
Lesenswert?
• ▲
▼

Seufz, vielleicht war ich oben nicht deutlich genug oder ich habe chinesisch geredet?!

Die beiden Abfragen (temp == 0xFB) bzw. (temp == 0xF8) sind einfach grob falsch. BP1 und BP0 im Status Register sind mitnichten '1' und '0'. Das sind die Block Protect Bits, und im Auslieferungszustand i. d. R. beide 0.

Das (temp == 0xFB) ist daher NIE richtig, es wird also NIE auf das Ende des Schreibvorgangs gewartet, womit natürlich nur Müll herauskommt.

Antwort Zitieren Bearbeiten Löschen Beitrag melden
mitlesa Gast #7347124
Lesenswert?
• ▲
▼

A. B. schrieb:

Das (temp == 0xFB) ist daher NIE richtig, es wird also NIE auf das Ende des Schreibvorgangs gewartet

.... was durch die sagenhafte delay-Routine noch verschleiert wird.

Eigentlich steht's ja schon länger da, aber beratungsresistente Leute sind ja immun gegen solche Hinweise:

eeprom writer schrieb:

dann prüft man das Write-in-progress-Bit bis es gelöscht ist

Antwort Zitieren Bearbeiten Löschen Beitrag melden
Bbbbb OP #7347228
Lesenswert?
• ▲
▼

A. B. schrieb:

Seufz, vielleicht war ich oben nicht deutlich genug oder ich habe chinesisch geredet?!

Die beiden Abfragen (temp == 0xFB) bzw. (temp == 0xF8) sind einfach grob falsch. BP1 und BP0 im Status Register sind mitnichten '1' und '0'. Das sind die Block Protect Bits, und im Auslieferungszustand i. d. R. beide 0.

Das (temp == 0xFB) ist daher NIE richtig, es wird also NIE auf das Ende des Schreibvorgangs gewartet, womit natürlich nur Müll herauskommt.

Wenn du dir den Code mal anschaust wirst du merken dass das im Prinzip Error-Handler sind die das Programm im Fall dass block protect bits gesetzt sind festhalten. Auf diese Art wollte ich sicher gehen, dass das keine Fehlerquelle ist. Außerdem sollte man auf das Ende des Schreibzyklus nicht vor sonder nach dem Schreiben warten was mit delay(writecycle) geschieht :)

Antwort Zitieren Bearbeiten Löschen Beitrag melden
Bbbbb OP #7347249
Lesenswert?
• ▲
▼

Vorrausgesetzt es würde immer ein Writebefehl folgen wäre es egal ob man vor oder nach dem Befehl wartet aber wenn zwischen den Write-Befehlen ein Read-Befehl kommt müsste dieser auch eine Routine aufweisen welche auf die Beendigung eines potentiellen Write-Befehls reagiert. Ist meiner Minung nach etwas umständlich im Vergleich zu einem Warte-Befehl am Ende eines Write-Zyklus

Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren