SPI-Softwareauswahl nicht niedrig bleiben

...und noch einiges mehr. Ich arbeite mich durch Geoffrey Browns Buch Discovering the STM32 Microcontroller und es ist bisher weitgehend reibungslos verlaufen. Ich bin auf eine Übung gestoßen, bei der der Leser versuchen kann, über SPI in ein EEPROM zu lesen / schreiben. Ich habe die SPI-Schnittstelle im Loopback arbeiten lassen, obwohl ich gestern Abend, als ich sie testete, bemerkte, dass ich auf dem Logikanalysator sah, dass das NSS hoch ging, bevor die Nachricht vollständig war. Dann morgens keine Änderung, alles funktioniert wieder einwandfrei. OK.

Ich habe alles zum Lesen/Schreiben des ROM (Micro 25LC256) eingerichtet, aber das Signal, das ich auf dem Analysator sehe, entspricht nicht meinen Erwartungen. Ich sehe, wie das NSS von Zeit zu Zeit mitten in der Kommunikation hochschiebt. Außerdem sieht die Uhr inkonsistent aus und die Daten sehen falsch aus, und der Analysator gibt mir eine Menge Fehler.

Ich dachte, OK, ich werde das NSS ganz entfernen, da das ROM sowieso das einzige ist, was angeschlossen ist, dann bleibt es niedrig und ich kann es überprüfen. Aber die Uhr sieht immer noch wackelig aus ... Ich fange gerade erst mit diesem Zeug an, aber ich habe überhaupt nichts, um die Taktfrequenz anzupassen, also bin ich mir nicht sicher, wie sich das ändert? Der Code kann hier gefunden werden , und ich denke, es ist ganz einfach. die meisten wichtigen Logik sieht aus

  // Drop select level low then send the write enable flag
  GPIO_WriteBit(EEPROM_PORT, EEPROM_CS, 0);
  spiReadWrite(EEPROM_SPI, res, cmd, 2, EEPROM_SPEED);
  GPIO_WriteBit(EEPROM_PORT, EEPROM_CS, 1);
  Delay(1); // Debugging aid, Wait 1 ms to make analyzer easier to read

Ich habe alle Geschwindigkeiten niedrig eingestellt (die SPI CLK/MOSI/MISO sind 72 / 64 = 1.125< 10Mhz= 25LC256 maximale Geschwindigkeit und der GPIO, den ich für NSS verwende, ist 2MHz), und ich habe eine Verzögerung zwischen den Operationen eingefügt, 1msnur um es einfacher zu machen zu lesen Auf dem Analysator scheint es die Ausgabe nicht zu beeinflussen.

Hier ist eine Erfassung der Analysatordaten mit dem NSS auf Low (ausgesteckt):

Geben Sie hier die Bildbeschreibung ein

Beim Vergrößern der ersten Impulse sehe ich, dass die Taktbreite überall ist, für mich nicht wie CPOL / CPHA = 0/0 aussieht und nicht so aussieht, als würde sie den Schreibfreigabewert senden WREN = 0x06 = 0b0000 0110...

Geben Sie hier die Bildbeschreibung ein

... und es scheint nicht besser zu werden ...

Geben Sie hier die Bildbeschreibung ein

Und ein letztes, das zeigt, wie der NSS ohne Grund hoch treibt

Geben Sie hier die Bildbeschreibung ein

Wie debugge ich von hier aus? Gibt es etwas Offensichtliches, das ich übersehe? Ist es üblich, solche schlecht aussehenden Timing-Probleme zu haben? Danke!

Als erstes fällt mir ein, dass Sie einen CS-Pin benötigen, um diesen Chip anzuschließen. Aus 3.2 im Datenblatt: "Nachdem alle acht Bits des Befehls übertragen wurden, muss CS auf High gebracht werden, um den Schreibfreigabe-Latch zu setzen". Zweitens, haben Sie den "Hold"-Pin richtig angeschlossen?
Mit welcher Geschwindigkeit tastet Ihr Logikanalysator ab? Sieht so aus, als wäre es im Verhältnis zu Ihrer SPI-Uhr zu langsam.
@brhans Ich habe es auf das Maximum eingestellt, das sind 50 MS / s. Ich denke, das sollte ausreichen, um ein < 2MHzSignal abzutasten?
@Maple Danke, ich weiß tatsächlich, dass der CS zum Setzen des Schreiblatches verwendet wird. Ich habe es nur deaktiviert, um zu sehen, ob ich das richtige Signal aus MOSI „erzwingen“ kann (ich erwarte zu sehen, 0x06welches der Wert für die Schreibfreigabe ist), aber es kommt noch nicht einmal so weit. Was den Haltestift betrifft, werde ich morgen früh noch einmal nachsehen, aber alles ist ziemlich einfach auf einem eigenen Steckbrett verbunden, daher bin ich mir ziemlich sicher, dass es gut verbunden ist.

Antworten (1)

Ein Teil, der ziemlich offensichtlich ist:

Lassen Sie Chip Select nicht die ganze Zeit unverbunden oder niedrig. Bei den meisten Slave-Geräten ist die Chipauswahl ein wesentlicher Bestandteil der Zustandsmaschine des Slaves. In EEPROMs beispielsweise wird das Schreiben in die eigentlichen Zellen oft durchgeführt, nachdem die Chipauswahl hoch geht.

Jetzt sehen Ihre Logikanalysator-Erfassungen sehr wackelig aus. Meine Vermutung ist, dass Sie etwas Rauschen in Ihren Leitungen haben (Kopplung von den anderen Leitungen, Masseschleifen), sodass Sie nicht wirklich sehen, was dort wirklich vor sich geht. Ich habe auch Berichte von Kollegen erhalten, dass der Logikanalysator selbst ziemlich viel Rauschen erzeugt.

Sie haben nicht erwähnt, ob Sie sich tatsächlich angesehen haben, was die Software Ihnen sagt - bekommen Sie, dass der Lesepuffer derselbe ist wie der, den Sie geschrieben haben? Das ist das Wichtigste, worüber Sie sich Sorgen machen sollten. Wenn dies nicht der Fall ist, können Sie sich den Bus ansehen, aber vorher würde ich versuchen, zu sehen, was ich im Debugger bekommen kann.

Wenn Ihr Analysator den Analogmodus unterstützt, kann es sich lohnen, analoge Signale zu untersuchen, um festzustellen, ob einige der Flanken erhebliches Rauschen auf den anderen Leitungen verursachen. Oder natürlich ein Oszilloskop verwenden.

Danke! Ich habe die Werte im ROM überprüft und sehe meine Schreibvorgänge nicht, aber ich bekomme die korrekte Anzahl von Nullwerten zurück, wenn ich den Debugger einchecke (ich lasse die gesamte erste Seite ziehen und bekomme 64 Nullen zurück , was ein gutes Zeichen zu sein scheint). Es macht die Situation tatsächlich verwirrender, da ich, wenn das Lesen korrekt funktioniert, mit den Schreibvorgängen nur etwas in der Software falsch sein könnte (weshalb ich überhaupt versucht habe, mit dem Logikanalysator zu debuggen), aber einfach nicht in der Lage bin, Fehler zu beheben es wegen Analysatorproblemen. :-/
Aufgrund Ihrer Antwort habe ich alle Gründe mit einer besseren Quelle verknüpft. Es stellt sich heraus, dass die Masse, die ich für den CS-Pin verwendet habe, verrückt ist (wahrscheinlich ist die gesamte Platine irgendwie fehlerhaft). Ich bekomme jetzt ein klareres Signal, obwohl etwas noch etwas daneben zu sein scheint. Vielen Dank für Ihre Hilfe!
Nochmals vielen Dank für die Hilfe. Ich akzeptiere Ihre Antwort, da sie mich zum Laufen gebracht hat. Der Logikanalysator hat noch ein kleines Rauschen, aber ich habe alles sehr schön zum summen gebracht. Ich bin mir nicht sicher, wie das möglich ist, aber einer der Erdungsstifte auf meinem Discovery Board macht eine Menge Lärm, obwohl der Rest des Boards gut zu funktionieren scheint. Mein Verdacht ist, dass die anderen Gründe für den Rest des unberechenbaren Verhaltens verantwortlich sein könnten, das ich auf dem Analysator sehe, aber da es funktioniert, werde ich es jetzt nicht verrückt machen, das zu testen.
@TrivialCase Wenn einer der Massestifte viel zusätzliches Rauschen verursacht, kann es sein, dass er nicht mit Masse (schlechtes Löten?) Oder einer anderen Masse verbunden ist (einige Platinen haben getrennte Masse, aber das glaube ich nicht ist bei den Discovery Boards der Fall). Könnte auch sein, dass der Pin eine schlechte Führung zur Masse hat (lange Schleife statt direkt zur Ebene). Freut mich, dass ich dir ein bisschen helfen konnte.