Hallo und guten Tag, mit einem 32bit Mikrocontroller sollen gewisse Daten in ein eeprom abgelegt werden. Hierfür möchten wir das eeprom M95M02 einsetzen. Aktuell bin ich dabei den SPI Treiber zu implementieren. Mit dem OSzi kann ich auch die SIgnal CLK, CS, MISO und MOSI analysieren. Das Versenden von Kommandos müsste soweit passen nur der EMpfang funktioniert nicht. Gibt es gewisse Punkte die bei dier Verwendung des eeproms beachtet werden müssen?
> nur der EMpfang funktioniert nicht
Wie äußert sich das? Gibt es Aktivität auf der MISO-Leitung?
Passt die von Dir gewählte SPI-Betriebsart zu einer, die das EEPROM
versteht?
(die findest Du im Datenblatt auf S. 12).
Mit welcher Taktfrequenz arbeitest Du? Was machst Du mit dem /Hold-Pin?
sonde schrieb: > Gibt es gewisse Punkte die bei dier Verwendung des eeproms beachtet > werden müssen? Ja - natürlich. Das ist alles im Datenblatt beschrieben.
sonde schrieb: > Gibt es gewisse Punkte die bei dier Verwendung des > eeproms beachtet werden müssen? Ohne Abblock-Kondensator am EEPROM wird es nicht funktionieren. Jedenfalls nicht zuverlässig. Echt jetzt.
- SPU Taktfrequenz: ~5Mhz - SPI Mode: CLKPOL=0, CLKPHA=0 - Blockkondensatoren muss ich noch nachrüsten zwischen Vcc und Gnd. - An den MISO, MOSI, CLK hängt noch parallel ein anderer Spi Speicherbaustein. Dieser wird aber aktuell nicht benutzt. Da habe ich den CS permanent auf '1' geschaltet.
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...
:
Bearbeitet durch Moderator
sonde schrieb: > Da habe ich den CS permanent auf '1' geschaltet. Hoffentlich handelt es sich um ein 'not CS', sonst gibt es mit der '1' ein Problem.
Bei dem anderen Baustein ist der CS an einem anderen Mikrocontroller Gpio Pin abgeschlossen. Diesen habe ich noch zusätzlich auf High geschaltet.
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?
:
Bearbeitet durch Moderator
Sorry hab mich wohl etwas falsch ausgedrückt. Natürlich sind beide SPI Bausteine am selben Mikrocontroller angeschlossen. Die beiden Bausteine teilen sich die Pins MISO, MOSI, CLK. Nur die CS sind am Mikrocontroller an verschiedenen IO Pins angeschlossen
Die wichtigste Aussage wird von angehenden EEPROM-Programmierern oft nicht beachtet bzw. übersehen (Datenblatt Seite 17):
1 | The Write enable latch (WEL) bit must be set prior to |
2 | each WRITE and WRSR instruction. The only way to do this |
3 | is to send a Write enable instruction to the device. |
Guten Morgen, bevor das Kommando M95M02_CMD_WRITE = 0x02 ausgeführt wird sende ich das Kommando M95M02_CMD_WREN = 0x02. Leider kann ich nichts empfangen.
sonde schrieb: > Leider kann ich nichts empfangen. Warum solltest du auch was empfangen wenn du etwas schreibst. Was erwartest du denn was kommen soll? Solch unklare Darstellungen helfen nicht weiter.
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.
:
Bearbeitet durch Moderator
sonde schrieb: > Die anderen Pins /W und /HOLD sind permanent auf 0V (Low Pegel) > geschaltet. Das ist bei /HOLD keine so gute Idee: > The Hold (/HOLD) signal is used to pause any serial communications > with the device without deselecting the device.
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: > Pin 3 & 7 liegen auf VCC Du widersprichst Dir: sonde schrieb: > Die anderen Pins /W und /HOLD sind permanent auf 0V (Low Pegel) > geschaltet.
1 | USART_SpiTransfer( USART0, M95M02_CMD_WREN ); |
2 | |
3 | uint8_t retVal = 0; |
4 | USART_SpiTransfer(USART0, M95M02_CMD_RDSR); |
5 | retVal = USART_SpiTransfer(USART0, 0); |
Der Wert von retVal ist immer 0.
Aha. Kannst Du auch diese Frage hier beantworten: DerEgon schrieb: > Wie äußert sich das? Gibt es Aktivität auf der MISO-Leitung? sonde schrieb: > bevor das Kommando M95M02_CMD_WRITE = 0x02 ausgeführt wird sende ich > das Kommando M95M02_CMD_WREN = 0x02. Hast Du auch schon mal einfache Lesezugriffe ausprobiert?
Angehängte Dateien:
-
M95M02_S.PNG
50 KB
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.
:
Bearbeitet durch Moderator
SPI Clock läuft mit ~3Mhz. EInfache Lesezugriffe habe ich so noch nicht gemacht. Es gibt ja nicht wie bei dem Flash Bausteine die Möglichkeit die ID auszulesen. Das wäre super.
So jetzt habe ich auch nach jedem Kommando den CS auf low und danach auf high gesetzt. Tut immer noch nicht.
Ist natürlich falsch: So jetzt habe ich auch nach jedem Kommando den CS auf low und danach auf high gesetzt. Tut immer noch nicht. Vor jedem Kommando wird CS auf low gesetzt und danach wieder auf high.
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.
Angehängte Dateien:
-
scope_spi_communication.png
130 KB
Hier ein Bild vom Oszilloskope: 1. SPI Übertragung mit dem Kommando 0x05 2. SPI Übertragung mit dem Datenbyte 0xFF
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?
:
Bearbeitet durch Moderator
Ich habe den MSIO-Pin bereits entfernt und direkt daran gemessen. Ist genauso wie im Bild.
Du willst das Statusregister lesen? (Kommando 0x05) Dann muss Chipselect (rot?) zwischem dem ersten und zweiten Byte unbedingt low bleiben.
:
Bearbeitet durch User
Angehängte Dateien:
-
M95M02_RDSR.PNG
67 KB
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.
:
Bearbeitet durch Moderator
Der grüne Kanal ist MISO. Ja es ist ein SO8 Gehäuse. MOSI ist permanent auf 0V. CS habe ich nun auch abgeändert. CS wird erst nach dem 2. Byte wieder auf high gesetzt. Der Ausgang bleibt nach wie vor auf 0.
Ich weiß nicht woran ich mich noch halten soll. Ich habe keine Idee mehr was ich noch tun könnte. Das Timing der Signal sieht gut aus.
Wenn ich den Status (Register 0x05) auslese, welchen Wert sollte ich dann erhalten?
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.
Angehängte Dateien:
-
M95M02_Reset.PNG
61 KB
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"
Siehe da ich lese den Wert 0x02 aus. Ich habe nun das Kommando WREN davor gesendet. Im Datenblatt steht das nicht explizit drin dass man das vor dem Read Status Register ausführen soll.
Um Daten in das eeprom zu schreiben müssen dann folgende Bits vom Statusregister auf 0 gesetzt werden: WEL = 0 WIP = 0 SRWD = 0 BP1 = 0 BP2 = 0 Sehe ich das richtig so?
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.
Angehängte Dateien:
-
M95M02_WEL.PNG
23 KB
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.
:
Bearbeitet durch Moderator
Ok nachdem ich nun das Stutus Register auf 0 gesetzt habe lese ich nun immer wieder 0 aus. Ich hoffe das passt soweit. Irgendwie trau ich dem ganzen nicht so.
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.
Wenn ich Daten in das eeprom schreiben möcht wie läuft das ab: Send Kommando WREN Send Kommando WRITE Send Adresse (Bit 17..24) Send Adresse (Bit 9...16) Send Adresse (Bit 0...8) Send Datenbyte
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.
:
Bearbeitet durch Moderator
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?
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.