eeprom M95M02

sonde schrieb:
> Mit dem OSzi kann ich auch die SIgnal CLK, CS, MISO und MOSI
> analysieren.
Und wie sehen diese Signale direkt an den Pins des EEPproms aus?

Schöne stetige Flanken ohne Klingeln?

> Gibt es gewisse Punkte die bei dier Verwendung des eeproms beachtet
> werden müssen?
Verhält sich das Timing auf Bitebene so, wie es im Datenblatt steht?

Verhält sich das Timing auf Wortebene so, wie es im Datenblatt steht?

sonde schrieb:
> Blockkondensatoren muss ich noch
> nachrüsten zwischen Vcc und Gnd.
Ja, so halt, wie es im Datenblatt steht.

Wenn das soweit passt, dann liest du zuerst mal das ID-Register aus...

sonde schrieb:
> welches Register genau?
Blöd auch, daß Ding hat kein ID-Register. Dann muss also das 
Statusregister herhalten. Da sind ach einem Powerup wenigstens 2 Bits 
definiert...

sonde schrieb:
> Gibt es gewisse Punkte die bei dier Verwendung des eeproms beachtet
> werden müssen?
Die anderen Pins /W und /HOLD müssen entsprechend dem Bild 5 auch einen 
definierten Zustand haben.

sonde schrieb:
> Bei dem anderen Baustein ist der CS an einem anderen Mikrocontroller
> Gpio Pin abgeschlossen.
Ui, interessantes Konzept.
Aber dieser uC hängt sonst nicht mit an diesem SPI-Bus?

sonde schrieb:
> Leider kann ich nichts empfangen.
So ausdauernd, wie du da von "nichts empfangen" schreibst, solltest du 
dir dringend mal anschauen, was SPI ist und wie der funktioniert.

Denn weil SPI einfach nur gekoppelte Schieberegister sind, empfängst du 
immer gleichzeitig jeweils dann ein Bit, wenn du eines sendest. Ob das 
Bit irgendwelche Information trägt, und welche das ist, das steht im 
Datenblatt.

sonde schrieb:
> Mit dem OSzi kann ich auch die SIgnal CLK, CS, MISO und MOSI analysieren.
Zeig doch mal Bilder davon. Wieviele Kanäle hat dein Oszi? Zur Analyse 
von SPI wäre ein 4-Kanal-Oszi schon nicht schlecht. Bei einem 
2-Kanal-Oszi muss man sich das Protokoll aufwendig zusammenbasteln.

Signal Description Abschnitt im Datenblatt[1] lesen und verstehen, oder 
konkret nachfragen, wenn da was unverständlich ist. /HOLD ist low 
active. Mit 0V am Pin, stellt sich der Baustein am SPI tot.

[1] https://www.st.com/resource/en/datasheet/m95m02-dr.pdf

DerEgon schrieb:
> Das ist bei /HOLD keine so gute Idee:
Tatsächlich.
"During the Hold condition, the Serial data output (Q) is high 
impedance, and Serial data input (D) and Serial clock (C) are Don’t 
care."

Und das steht sogar zweimal im DB: einmal bei 3.5 und mit gleichem Text 
bei 5.3

Lies mal nach dem WREN das RDSR aus, ob das WEL = 1 ist. Alle anderen 
Bits müssen 0 sein.

sonde schrieb:
> Das CS Signal wird nach der SPi Initialiserung permanent auf 0V
> geschaltet.
So geht das nicht. Sieh dir nochmal genau an, wofür das CS-Signal da 
ist. In jedem_ Timing-Diagramm im Datenblatt ist es _vor einer 
Übertragung high, nur_ während der Übertragung low und wird _danach 
wieder high.

Der /S ist der Framesync, wenn der 1 ist, dann wird der SPI-Automat im 
EEPROM zurückgesetzt. Das steht wiederholt bei 6.1 und 6.2 ...

Und was hatte ich gestern abend um 19:38 geschrieben: wenn du das 
Signaltiming laut DB einhältst, dann geht das.

Beantworte bitte mal die Fragen zum Oszilloskop.

Denn es ist bei der Inbetriebnahme eines Prototypen m.E. so ziemlich das 
Einfachste, so ein EEPROM mit gerade mal 4 Kommunikationspins Pins zum 
Laufen zu bringen.

Und so wie ich den bisherigen Verlauf des Threads interpretiere, ist bei 
Weitem nicht sicher, ob das Timing auf Bit- und Wortebene tatsächlich 
passt.

sonde schrieb:
> 2. SPI Übertragung mit dem Datenbyte 0xFF

Das Bild zeigt aber 0x00.

Schalte mal den Pullup für MISO ein, dann muß MISO in den /CS-Pausen 
langsam auf high gehen.

sonde schrieb:
> Hier ein Bild vom Oszilloskope
Und der grüne Kanal ist der MISO?

Also, das sieht ja gar nicht mal so ohne aus. Nach Buskollision sieht 
das nicht aus. Eher einem Kurzschluss. Aber das hast du sicher schon 
geprüft.

Hast du das SO8-Gehäuse? Was passiert, wenn du den MSIO-Pin ablötest und 
direkt daran misst?

> SPI Übertragung mit dem Datenbyte 0xFF
Die 0xo5 passt, die tauch auf dem MOSI auf. Auch die Timings passen zum 
Datenblatt. Aber da ist nirgends ein Datenbyte 0xFF weder auf dem MOSI 
noch auf dem MISO zu sehen.

> Hier ein Bild vom Oszilloskope:
BTW: wenn du die Signale so sortierst, wie sie im DB stehen, dann fällt 
der Vergleich nicht so schwer...

sonde schrieb:
> Ja stimmt da zweite Byte ist 0x00.
Wie oft kann man sich eigentlich irren?

> Auch mit 0xFF tut es nicht.
Was "tut nicht"? Kommen dann diese FF wenigstens am MOSI heraus?

Du willst das Statusregister lesen? (Kommando 0x05)

Dann muss Chipselect (rot?) zwischem dem ersten und zweiten Byte 
unbedingt low bleiben.

Pat A. schrieb:
> Du willst das Statusregister lesen? (Kommando 0x05)
> Dann muss Chipselect (rot?) zwischem dem ersten und zweitem Byte
> unbedingt low bleiben.

Lothar M. schrieb:
> Ja, so halt, wie es im Datenblatt steht.
@sonde: Lies das Ding. Halte dich daran.

sonde schrieb:
> Wenn ich den Status (Register 0x05) auslese, welchen Wert sollte ich
> dann erhalten?

Im Normalfall 0x00 ;-)

Setz' mal ein WREN-Kommando (write enable, 0x06) ab und lies dann das 
Statusregister aus: der Wert sollte nun 0x02 sein.

sonde schrieb:
> Wenn ich den Status (Register 0x05) auslese, welchen Wert sollte ich
> dann erhalten?
So wie ich das sehe genau das, was du siehst, so lange du da drin nicht 
ein Bit änderst. Siehe das DB Kapitel 5.1.2 Device Reset.

Es sieht so aus, als ob du mit dem WRSR Kommando erst mal ein paar Bits 
umbiegen musst:
"The Write Status register (WRSR) instruction enables the user
to change the values of the BP1, BP0 and SRWD bits"

sonde schrieb:
> Im Datenblatt steht das nicht explizit drin dass man das
> vor dem Read Status Register ausführen soll.

Um das Statusregister zu lesen muss man das auch nicht ;-)
Aber um Daten zu schreiben, ist WREN nötig.

Nein, am Statusregister muss nichts geändert werden, um Daten zu 
schreiben.

Und vorab noch ein Tipp: wenn Du Daten geschrieben hast (max. eine 
Page), dann solange das Statusregister pollen bis Bit[0]=0.

sonde schrieb:
> Sehe ich das richtig so?
Lies im DB 6.3.2 WEL bit

Du musst vor jedem einzelnen Schreibbefehl das WREN Kommando abschicken, 
denn am Ende eines Schreibbefehls wird das Bit zurückgesetzt.

sonde schrieb:
> Siehe da ich lese den Wert 0x02 aus.
Na bitte, jetzt kannst du 1x einen Schreibbefehl ausführen.

sonde schrieb:
> Ok nachdem ich nun das Stutus Register auf 0 gesetzt habe lese ich nun
> immer wieder 0 aus. Ich hoffe das passt soweit.
Ja, du musst in die Statusregister Bits schon was anderes als 0 
reinschreiben oder eben mit WREN das WEL wieder setzen.

Pat A. schrieb:
> noch ein Tipp: wenn Du Daten geschrieben hast (max. eine Page), dann
> solange das Statusregister pollen bis Bit[0]=0.
Dazu kann laut Kapitel 6.3 Bild 10 der /S dauerhaft auf low bleiben. Mir 
erscheint das Warten aufs EEPROM aber wie Rechenzeitverschwendung.

Alternativ kann man nämlich während der tw=10ms was Sinnvolles tun und 
vor dem nächsten Schreiben nochmal schauen, ob der vorige Schreibvorgang 
inzwischen schon beendet ist.

Datenblatt anschauen und ausprobieren: Kapitel 6.6 Write to Memory array 
(WRITE)

Und vorher den /S auf low und danach den /S wieder auf high.

Eben genau so wie im Bild 13 des DB.

Und dann der Einfachheit halber noch 15ms warten.

sonde schrieb:
> Die 15ms Wartezeit erfolgt dies nach jeden Schreiben eines Bytes?
Ach geh, das kannst du doch selber.

Was steht bei tw im Datenblatt? Und was steht im Kapitel 6.6 des DB im 
Absatz 2?