Hi, habe folgendes Problem am SPI Bus (nur senden,Empfang interessiert nicht) Situation 1: jeweils einen Tastkopf (8pF) an CLK und an MOSI. Signale sehen lehrbuchmäßig aus und von den Phasen bzw. Timing so wie im Datenblatt des Slaves (TRF7962A) gefordert.Kommunikation schlägt jedoch fehl Situation 2: nur noch ein Tastkopf an MOSI. Kommunikation funktioniert. Situation 3: überhaupt kein Tastkopf. Keine Kommunikation. Situtation 4: Zwei Tastköpfe an MOSI, einer an CLK. Signale sehen exakt aus wie in Situation 1 beschrieben. Kommunikation funktioniert. Meine Schlussfolgerung: Ist die Kapazität an MOSI größer als an CLK geht alles, wenn nicht, dann nicht. Frage ist nur, warum? Ob der Massanschluss der Tastköpfe mit der Schaltungsmasse verbunden ist spielt übrigens keine Rolle. Ich kann das Ganze auch nachstellen, wenn ich einen kleinen C zwischen MISO und GND hänge. Jemand ein Idee?
:
Bearbeitet durch User
Hi
>Jemand ein Idee?
Dir ist aber schon aufgefallen, das für Schreiben und Lesen
unterschiedliche SPI-Modes verwendet werden? Berücksichtigt?
MfG Spess
Chris H. schrieb: > Jemand ein Idee? Mit der kapazitiven Belastung verzögerst du Flanken. Mit dem Tastkopf an MOSI verschiebst du die Flanken so weit, dass bei der Clock-Flanke noch das richtige Signal anliegt. Wenn das so kritisch ist, erfolgt der Signalwechsel auf der falschen Flanke. > Signale sehen lehrbuchmäßig aus ... Bist du sicher, dass du mit der richtigen Seite im Lehrbuch vergleichst. Es gibt 4 SPI Modi.
So trivial (falscher SPI Modus) ist das Problem leider nicht. In meinem Fall werden die Daten bei fallender Taktflanke vom Master auf den Bus gepackt und bei steigender vom Slave eingelesen. So will es der Slave laut Datenbaltt und so bekommt er es auch. Wie gesagt, auf dem Scope sieht es sauber aus. Eine zeitliche Verschiebung der Taktflanken war auch mein erster Gedanke, hat sich aber leider nicht bestätigt. Die Kapazitäten der Tastköpfe sind zu gering. Ausserdem, wie bereits geschrieben, sehen die Signal bei Situation 1 und 4 (siehe oberster Beitrag) exakt gleich aus, mit dem Unterschied dass Situation 4 funktioniert, Situation 1 nicht. Zeitliche Verschiebungen der Flanken durch die Kapazitäten kann ich selbst bei höchster Auflösung nicht erkennen (Tektronix MSO4000)
Chris H. schrieb: > So trivial (falscher SPI Modus) ist das Problem leider nicht. Nein, natürlich nicht. Dein Problem ist noch viel trivialer. Wahrscheinlich fehlen wieder einmal nur die Stützkondensatoren.
100nF schrieb: > Dein Problem ist noch viel trivialer. Wahrscheinlich fehlen wieder > einmal nur die Stützkondensatoren. Nein, da hab ich "leider" dran gedacht.
Chris H. schrieb: > Das ist definitiv blödsinn Was allerdimgs definitiv kein Blödsinn ist, ist, daß es hier so ziemlich jedem scheissegal ist, ob deine Schaltung funktioniert oder nicht. "Leider". Schon dran gedacht, deine Tastköpfe einzulöten? Damit geht es doch, oder?
100nF schrieb: > Was allerdimgs definitiv kein Blödsinn ist, ist, daß es hier so ziemlich > jedem scheissegal ist, ob deine Schaltung funktioniert oder nicht. > "Leider". sie funktioniert ja ;) > Schon dran gedacht, deine Tastköpfe einzulöten? Damit geht es doch, > oder? Ein Kondensator tuts auch
Chris H. schrieb: > Situation 2: > > nur noch ein Tastkopf an MOSI. Kommunikation funktioniert. Dann pack/löte/klebe doch einen kleinen Kerko (8pF bietet sich an ;-)) an MOSI. Als Tastkopfersatz...
:
Bearbeitet durch User
Chris H. schrieb: > .Kommunikation schlägt jedoch fehl > Situation 2: > nur noch ein Tastkopf an MOSI. Kommunikation funktioniert. Falscher SPI-Modus. Das wars bei solchen Fehlern bei mir bisher immer... :-/ Hast du einfach mal die anderen 3 SPI Modes ausprobiert? Nur zur Sicherheit... spess53 schrieb: > Dir ist aber schon aufgefallen, das für Schreiben und Lesen > unterschiedliche SPI-Modes verwendet werden? Wer macht denn sowas? Diese Schnittstelle sieht mir verdächtig nach Murks aus. Hat das der Prakti hingebastelt?
:
Bearbeitet durch Moderator
Lothar M. schrieb: > spess53 schrieb: >> Dir ist aber schon aufgefallen, das für Schreiben und Lesen >> unterschiedliche SPI-Modes verwendet werden? > Wer macht denn sowas? Diese Schnittstelle sieht mir verdächtig nach > Murks aus. Hat das der Prakti hingebastelt? Sowas macht Texas Instruments :) Ich benutze den Lesemodus aber nicht. Ich schreibe lediglich. Und ich benutze definitiv den richtigen SPI Mode. Es funktioniert ja auch absolut zuverlässig, wenn die Kapazität am MOSI ca. 10pf größer ist als an Clock.
:
Bearbeitet durch User
Lothar M. schrieb: > Hast du einfach mal die anderen 3 SPI Modes ausprobiert? Bestimmt nicht, das wäre ja zu einfach. Besser die anderen alle für doof halten. "Was, nur ein Geisterfahrer, nein hunderte." Ich hab schon öfter widersprüchliche Angaben in Datenblättern gesehen. Ich hab natürlich keinen Bock mehr, da noch reinzuschauen.
:
Bearbeitet durch User
Chris H. schrieb: > Und ich benutze definitiv den richtigen SPI Mode. Ich würde diesen Datenblatt keinen halben Meter über den Weg trauen... Meine Vorhehensweise wäre: 1. Geschwindigkeit reduzieren 2. Die anderen 3 Modi ausprobieren
Wenn es am sehr knappen Timing liegt und du noch etwas Platz auf der Platine bzw. die Möglichkeit zum einbauen hast: Einfach in die "empfindliche" Signalleitung einen nichtinvertierenden Buffer einbauen. Der verzögert das Signal um ca. 5ns, was möglicherweise schon ausreichen könnte um eine zuverlässige Kommunikation zu erzeugen.
Wobei "sehr knappes Timing" bei SPI eigentlich nur mit zu hoher Taktfrequenz oder falschem SPI Mode erreicht werden kann. Sonst ist das Interface wegen der Synchronizität einfach zu beherrschen.
Chris H. schrieb: > Situation 1: > > jeweils einen Tastkopf (8pF) an CLK und an MOSI. Signale sehen > lehrbuchmäßig aus und von den Phasen bzw. Timing so wie im Datenblatt > des Slaves (TRF7962A) gefordert.Kommunikation schlägt jedoch fehl > > Situation 2: > > nur noch ein Tastkopf an MOSI. Kommunikation funktioniert. > > Situation 3: > > überhaupt kein Tastkopf. Keine Kommunikation. > > Situtation 4: > > Zwei Tastköpfe an MOSI, einer an CLK. Signale sehen exakt aus wie in > Situation 1 beschrieben. Kommunikation funktioniert. Das Problem kommt mir von einem TRF7961 (ISO15693 only) sehr bekannt vor. Wir haben damals bei TI nachgefragt und die Ursache gemeinsam gesucht. (Das Produkt war schon länger im Sortiment ohne Probleme, ohne Änderungen im Layout/Schaltplan) Vor dem Löten waren die Chips im Tester von TI völlig OK , danach (nur durch den Ofen, blank ohne Lötzinn durch den Ofen, nie elektrisch betrieben) fielen die in einigen Bereichen (Logikteil) auf dem Tester durch. Das Phänomen mit den Kapazitäten an SPI hatten wir in der gleichen Form. Hat uns sehr verwirrt. Gab auch noch ein paar weitere Symptome: Es kam z.b. vor, dass die Frame-Generierung aus dem Tritt kam und bis zum nächsten SW Reset kontinuierlich logische 0en auf dem RF Signal generierte ... Mit Hilfe von TI haben wir Probleme beim Löten ausgemacht und korrigiert. Das Reflow-Profil wurde angepasst, neue TRFs bei anderem Distri bestellt. Bei der nächsten Charge war dann alles wieder normal. Die bereits bestückten LP haben wir um einen kleinen C an MOSI und MISO erweitert. Laufen. Sind aber aussortiert in meinem Schrank ;-) Verkaufen würd' ich die nicht mehr.
Maxx schrieb: > Mit Hilfe von TI haben wir Probleme beim Löten ausgemacht und > korrigiert. Daß ein Fehler nicht mehr auftritt, heißt noch lange nicht, daß auch die Ursache gefunden wurde. Es kann sein, daß durch die höhere Temperatur Wasser austritt und damit die internen Schaltungskapazitäten etwas kleiner werden. Ich würde trotzdem die anderen SPI-Modi testen, nicht immer sind Supportmitarbeiter auch die hellsten Leuchten. Eine weitere Gefahr sehe ich in dem Mode ohne /SS-Pin. Den sollte man immer vermeiden, da wenn einmal die Synchronisation verloren geht, sie bis zum nächsten Power-On verloren bleibt.
Peter D. schrieb: > Eine weitere Gefahr sehe ich in dem Mode ohne /SS-Pin. SPI ist nur mit SS als Framesync sinnvoll (so ist er ursprünglich auch definiert). Wehe im anderem Mode kommt ein kleiner EMV-Spike, dann kommt das Ding fast unmöglich wieder auf die Spur...
Peter D. schrieb: > Daß ein Fehler nicht mehr auftritt, heißt noch lange nicht, daß auch die > Ursache gefunden wurde. Nein. Alleine Davon natürlich nicht. Aber der beschriebene Ablauf DUT, OK -> Ofen -> DUT fehlerhaft weist schon mit nem Zaunpfahl in diese Richtung. Ein danach im Ofen mitgefahrener Temperaturlogger, der ein nicht konformes Profil aufzeichnete, verdichtet das dann. Da das Fehlerbild sehr konsistent war und mit dem TE übereinstimmt, kann man das durchaus mal testen. PS: Es ist kein normaler SPI Modus MOSI/MISO wechseln zu unterscheidlichen Flanken. Siehe Errata zum TRF796x.
Maxx schrieb: > PS: Es ist kein normaler SPI Modus MOSI/MISO wechseln zu > unterscheidlichen Flanken. Siehe Errata zum TRF796x. Das erklärt natürlich einiges, da hat der Entwickler des Chips gepennt oder schlichtweg das SPI nicht verstanden. Master und Slave müssen mit der gleichen Flanke das Datenbit wechseln und mit der entgegengesetzten Flanke einlesen. Es sollte aber trotzdem gehen, wenn man das Master-SPI so einstellt, daß das Senden richtig ist. Der Slave sendet dann zwar auf der falschen Flanke, aber das MISO wird ja durch mehrere Laufzeiten gegenüber SCK verzögert. Es kann schon rein logisch nicht gleichzeitig mit SCK des Masters wechseln. Man müßte mal prüfen, welche minimale Durchlaufzeit der Chip von SCK_in zu MISO_out hat und welche minimale Hold-Zeit dem Master reicht.
Bei SPI ist Ringing oft ein Problem: zu steile Flanken erzeugen mehrere Clocks. Einfache Abhilfe: serieller Dämpfungs-R (10-100 Ohm) auf der Senderseite. Das ergibt mit der Leitungs- und Eingangs-Kapazität ein RC-Filter. Ein C nach Gnd verschlimmbessert die Situation meist, da der erhöhte Umladestrom auf benachbarte Leitungen transformiert wird. > Meine Vorhehensweise wäre: > 1. Geschwindigkeit reduzieren In diesem Fall bringt das nichts, da die Flanken dadurch nicht flacher werden. Sauber abgeblockte Versorgung und Masseverbindung tun ihr übriges.
@Maxx Na endlich mal jemand der mir nicht einreden möchte, ich hätte den falschen SPI Modus. Das ist ja "schön" wenn das gleiche ominöse Problem bei dir aufgetreten ist. Lötprobleme hatte ich auch vermutet nachdem im Grunde alles andere "abgeklopft" wurde. Kannst du mir sagen wie euer Lötprofil aussieht bzw. was ihr geändert habt. War das Problem nach den Änderungen komplett verschwunden?
Chris H. schrieb: > Na endlich mal jemand der mir nicht einreden möchte, ich hätte den > falschen SPI Modus. Nö, es wird nur vorgeschlagen, es mal zu testen. Sowas ist schnell gemacht. Welchen Du benutzt, weiß ja keiner. Wie gesagt, kritisch ist nur der Modus auf MOSI, der muß stimmen! Auf MISO hat man automatisch ein Delay. Einen ähnlichen Fall hat man, wenn man 74HC595 und 74HC165 als IO-Erweiterung nimmt. Der 74HC595 sampled mit der 0->1 Flanke, der 74HC165 legt die Daten aber auch mit der 0->1 Flanke an, autsch. Die Durchlaufzeit von SCK zu MISO im 74HC165 bewirkt aber, daß trotzdem alles im grünen Bereich ist.
Chris H. schrieb: > Na endlich mal jemand der mir nicht einreden möchte, ich hätte den > falschen SPI Modus. Hast du die anderen mal ausprobiert? Oder willst du einfach nur was anderes hören? Das mit dem "Dämpfungswiderstand" nennt sich eigentlich "Serienterminierung" und lässt sich ganz simpel mit einem Oszi ausmessen. Es hat mehr mit Leitungsimpedanz zu tun als mit Dämpfung... Beitrag "Re: Signalproblem bei langem Kabel" eProfi schrieb: >> Meine Vorhehensweise wäre: >> 1. Geschwindigkeit reduzieren > In diesem Fall bringt das nichts, da die Flanken dadurch nicht flacher > werden. Ich sag ja nur, dass das meine Vorgehensweise wäre. Ich sage nicht, dass damit ein Klingeln auf dem Signal reduziert würde. Ich hätte damit bewirkt, dass sich eine zu schnelle Übertragung nicht so schnell "verstolpert"...
:
Bearbeitet durch Moderator
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.