SPI-Takt - Problem mit langsamer Frequenz, aber schneller Anstiegszeit bei Wellenformen

Hintergrund zum Thema:

Ich habe derzeit einen SPI-Bus zwischen einem Atmel ATSAM3X8E und einem Spansion FL164K Flash-Speicherchip.

SPI war für mich in früheren Projekten immer super zuverlässig, aber dieses Design ist sehr temperamentvoll (das Routing ist alles andere als ideal). Einige Boards funktionieren gut, einige haben sehr gelegentliche Datenverluste in der SPI-Kommunikation, andere haben nahezu konstanten Datenverlust. Der Datenverlust, auf den ich mich beziehe, lässt sich am einfachsten reproduzieren, indem das Bereit-Flag während eines 50-sekündigen Löschvorgangs ständig abgefragt wird. Meistens ist die Besetzt-Antwort 0x03 (0b00000011), kommt aber gelegentlich als nicht beschäftigt zurück - 0x00 (0b00000000).

Glücklicherweise kann ich den Fehler auf der Bank reproduzieren, und glücklicherweise kann ich das Problem auch beseitigen. Leider ist das Anschließen einer passiven Sonde eines der Dinge, die das Problem beseitigen, sodass ich den Fehler nicht „sehen“ kann. Und ich nenne es nicht gerne repariert, wenn ich mir nicht sicher bin, was ich eigentlich repariere.

Informationen zum Schaltungsdesign:

• Der SPI-Bus wird an 3 Dinge geleitet - SPI-Flash, SD-Karte (die nicht installiert ist) und eine einfache 6-Pin-Stiftleiste
• Das rote Pad unten rechts ist die MCU (clk-Quelle), der Stub, der sofort abgeht, geht zu einem n-Kanal-FET, der eine LED ansteuert, der SOIC8-IC mit dem roten Pad ist der SPI-Blitz, der 6-Pin-Header darüber Es ist unbestückt, und das blaue Pad auf der linken Seite der Spur ist ein unbestückter SD-Kartenanschluss.
• Der tatsächliche Abstand von der MCU zum SPI-Flash beträgt ~35 mm und der SPI-Flash zum SD-Kartenpad beträgt ~30 mm. Der Stub zum FET ist ~25 mm und der Stub zum Header ist ~8 mm.
• Das Layout ist alles andere als ideal, und das verstehe ich, aber die Absicht war, es nur mit <1 MHz zu betreiben, daher bin ich fälschlicherweise davon ausgegangen, dass Übertragungsleitungstheorie/Abschlüsse/Reflexionen nicht benötigt werden.

Möglichkeiten, wie ich dem Problem bereits vorbeugen kann:

• Fügen Sie im 6-Pin-Header einen Keramikkondensator von CLK zur Masse hinzu (ich habe Werte von 18p bis 330p ausprobiert). Alle verlangsamen die Anstiegszeit, und das Problem besteht nicht fort
• Fügen Sie einen 1k-Widerstand von CLK zu Masse hinzu.
• Bringen Sie eine Oszilloskopsonde an
• Berühren Sie die CLK-Linie mit meinem Finger

Grundsätzlich scheint also jede Möglichkeit, der Schaltung Kapazität oder Belastung hinzuzufügen, die Lesevorgänge zu 100% zuverlässig zu machen.

Wellenformen (aufgenommen mit einem Rigol DS1054Z mit der 100-MHz-Option und einem passiven 150-MHz-Tastkopf mit Erdungsfeder):

Hinweis: Für all diese ist offensichtlich eine Oszilloskopsonde angeschlossen (was das Problem verhindert). Die Wellenformen, die wir hier sehen, sind eigentlich nicht schlimm genug, um das Problem zu verursachen, geben aber hoffentlich eine Vorstellung davon, was schlimm genug sein könnte, um das Problem zu verursachen, wenn die Kapazität der Sonde entfernt wird.

Hinweis 2: Diese Aufnahmen wurden mit einer Taktrate von 5 MHz aufgenommen, aber das Problem scheint sich irgendwo zwischen 100 kHz und 20 MHz zu manifestieren.

Auf den ersten Blick sieht das Taktsignal gut aus (wenn auch sehr schnelle Anstiegszeit von ~8 ns).

Aber eine Nahaufnahme zeigt eine kleine Stufe auf halber Höhe

Und auf der schnellsten Zeitskala sehe ich das hier.

Zum Schluss die Fragen

• Ist ein Schritt in der ansteigenden Wellenform typisch für Reflexionen von Übertragungsleitungen oder etwas anderes?
• Da das Leseproblem unabhängig von der Taktfrequenz auftritt, gehe ich davon aus, dass die Anstiegszeit (8 ns mit angeschlossener Sonde) mit dem schlechten Routing kombiniert werden muss, um die Datenprobleme zu verursachen. Aber verursachen schnelle Anstiegszeiten kein Klingeln, keine gestufte Wellenform? Ist es üblich, dass eine Oszilloskopsonde das sonst auftretende Klingeln dämpft?
• Wenn Sie sich die Wellenform ansehen, was passiert tatsächlich im Slave, um ein Problem zu verursachen? (Der SPI-Slave taktet aufgrund dieses Schritts doppelt? Oder der SPI-Flash erhält nicht die angegebene Anstiegsrate von 0,1 V / ns? Oder etwas anderes, das ich noch nicht verstehe?)
• Was könnte ich schließlich noch tun, um zu versuchen, das Signal zu bewerten, ohne das Signal zu laden (reparieren), außer $$$ für eine aktive Sonde auszugeben, die einen Unterschied machen kann oder nicht?

Wie Sie sehen können, ist die Hochfrequenztheorie nicht mein Fachgebiet, daher schätze ich die Erfahrungen aller auf diesem Gebiet.