MOSI Leitung aus CPLD mit "analogen" Pegelwerten

[Frickelfritze (Gast)]

Hat das schon mal jemand gesehen? Hat dafür jemand eine Erklärung?

Ein XC2C512 (XILINX Coolrunner für die die es nicht wissen) gibt auf
einem Ausgangspin stufige Pegel aus (sie Foto) während ein SPI Block
gesendet wird. Der korrespondierende SPI Clock Pin ist dagegen sauber
stabil. Das Ganze lässt sich bei hohen oder niedrigen Datenraten
reproduzieren. Gesteuert wird ein DDS AD9956.

- ja, die Versorgungsspannung von 3.3V ist stabil
- es sind keine Schwingungen oder Einbrüche auf der Versorgung sichtbar
- es gibt beim XC2C512 und beim AD9956 jede Menge Abblock Cs
- die Verbindung vom CPLD zum DDS ist "point to point"

[Achim S. (Gast)]

sieht für mich so aus, als würden zwei Ausgänge gegeneinander treiben. 
Der AD9956 kann seinen Serial Input auch als bidirektionalen Pin 
betreiben (ist sogar sein Default-Setting). Hast du ihm CFR1(7) auf 1 
gesetzt, damit dieser Pin nicht zwischendurch Daten treibt?

[Jan (Gast)]

Die GND-Pins sind auch alle niederohmig mit Masse verbunden?
Die Scope-Masse ist auch in der Nähe des (Mess-)Pins abgegriffen worden 
und nicht am Labornetzteil?

Sonst kann man ggf. durch GND-Loops auch alle möglichen Signale sehen, 
nur nicht das, was wirklich los ist.

Jan

[Uwe B. (uwe_beis)]

Achim S. schrieb:
> sieht für mich so aus, als würden zwei Ausgänge gegeneinander treiben.
Hätte ich auch zuerst getippt. Aber das ergibt max. nur 3 verschiedene 
Pegel, hier sind aber 4 zu sehen....

[Achim S. (Gast)]

Uwe B. schrieb:
> Hätte ich auch zuerst getippt. Aber das ergibt max. nur 3 verschiedene
> Pegel, hier sind aber 4 zu sehen....

3 Pegel würden sich beim Buskonflikt nur ergeben, wenn beide 
Kontrahenten gleich stark treiben. Die 4 Pegel kommen hin, wenn einer 
der beiden stärker treibt als der andere. Er zieht die Leitung dann 
jeweils etwas weiter in seine Richtung.

[Uwe B. (uwe_beis)]

Achim S. schrieb:
> Die 4 Pegel kommen hin, wenn einer
> der beiden stärker treibt als der andere.
Nein nein, warum sollten sich zwei unterschiedliche Pegel ergeben, wenn 
beide gleichzeitig treiben? Wenn beide ungleich sind - was ja eher die 
Regel ist - ergibt sich ein Pegel, der nicht in der Mitte ist, aber es 
ist immer nur dieser eine Pegel.

Aber da fällt mir ein: Wir haben ja eine Tabelle mit 4 Zuständen. Einer 
davon ist, wenn kein Ausgang treibt. Was ist, wenn in diesem Fall ein 
Pull-up auf VCC zieht, während mindesten einer der Ausgänge nur etwas 
weniger macht? Eher unwahrscheinlich, normalerweise erreichen die alle 
VCC. Aber wenn der Pull-up so schwach ist, dass er etwas weniger als VCC 
macht? Auch nicht plausibel, dann würde ich sichtbare Anstiegsflanken 
erwarten.

Noch 'ne Idee: Die beiden Ausgänge treiben verschiedene 
Ausgangsspannungen. Auf dem Oszi-Bild sieht es aus wie knapp 3V mehr als 
3.5V... Wo sollen die denn her kommen? Es sind immerhin ca. 0.8V 
Unterschied, also eher ca. 2.5V und 3.3V. Das scheint mir plausibel.

[Achim S. (Gast)]

Uwe B. schrieb:
> Nein nein, warum sollten sich zwei unterschiedliche Pegel ergeben, wenn
> beide gleichzeitig treiben?

Angenommen, das CPLD hat "doppelt so starke" Treiber wie der DDS-Chip. 
Dann ergeben sich beim Buskonflikt folgende 4 Pegel:

CPLD     DDS    resultierender Pegel
low      low     0V
high     high    3,3V
low      high    1/3 * 3,3V = 1,1V
high     low     2/3 * 3,3V = 2,2V

Für die beiden Fälle, in denen kein Buskonflikt auftritt (0V und 3,3V), 
ist es egal, ob der DDS dasselbe treibt wie das CPLD oder ob er high-Z 
ist.

Die tatsächlichen Spannungswerte hängen von den konkreten Treiberstärken 
der jeweiligen High- und Low-Side Treiber ab.

[Uwe B. (uwe_beis)]

Stimmt, du hast vollkommen recht. Das hätte mir nicht passieren dürfen, 
Asche auf mein Haupt. So dürfte es dann auch sein.

[Frickelfritze (Gast)]

So, zurück ais dem Urlaub komme ich jetzt dazu die Problematik
weiter zu verfolgen.

Ja es handelt sich offensichtlich um einen Buskonflikt. Die MOSI
Leitung meines CPLDs zum DDS ist mit einem Lämgswiderstand
ausgestattet der zum einen das Klingeln auf der Leitung verhindert
und - in diesem Fall ganz nützlich - auch verhindert dass durch zu
viel Stromfluss fliesst der bei einem solchen Buskonflikt vielleicht
die ganz Schaltung zusammenbrechen oder Chips kaputtgehen lässt.

Zur weiteren Erklärung: Die Baugruppe mit der erwähnten Anordnung
läuft seit Jahren in einem Gerät einwandfrei, die Ansteuerung
erfolgt dort über einen zentralen Mikroprozessor (Motorola 82xx).
"Interessehalber" habe ich nun die Ansteuerung der Baugruppe auf
einen mir nahestehenden Mikrokontroller portiert, seitdem tritt
eingangs erwähntes Problem auf, die Steuerung funktionierte von
vorne herein nicht.

Die Lösung des Problems ist ein explizites Ausschalten/Deaktivieren
des Chip Selects des DDS AD9956 nach jedem Schreibvorgang. Dieser CS
bleibt in der Gerätesoftware nach einem Schreibvorgang auf den DDS
aktiv, wird aber durch Ansprechen von anderen SPI Busteilnehmern im
Gerät mit Sicherheit wieder deaktiviert bevor ein neuer
Schreibvorgang auf den DDS startet. Scheinbar nicht bei der
Implementation auf dem Mikrokontroller. Es funktioniert auch ohne
des expliziten Setzens des DDS MOSI auf nur Input statt I/O.

Der Konflikt ist natürlich latent immer vorhanden solange die MOSI
Leitung des DDS per default auf I/O gesetzt ist, was aber eigentlich
keine Rolle spielen darf solange man nur Schreib-Befehle (die ja im
Steuerwort enthalten sind) auf den DDS ausgibt.

Da dies aber im Protokoll des DDS nur unzureichend (unbefriedigend,
ich hab's nicht gefunden) beschrieben ist bleibt hier für mich eine
Restunsicherheit in der Erklärung. Bei meiner Mikrokontroller-
Implementierung werden ja auch nur schreibende Zugriffe auf den DDS
gemacht. Ein mögliche Erklärung wäre dass der DDS, auch wenn er
einen Schreib-Befehl erhält, nach Auführen des Latch-Impulses seinen
MOSI auf OUTPUT setzt und weitere Clocks der SPI das Ausgeben von
Daten verursacht (solange der CS aktiv ist).

Nun ja, jedenfalls läuft die Steuerung jetzt auch auf dem
Mikrokontroller vollständig und ohne Bus Fight. Vielleicht hat der
eine oder andere noch etwas dazu beizutragen.

[Frickelfritze (Gast)]

Frickelfritze schrieb:
> auch verhindert dass durch zu
> viel Stromfluss fliesst der bei einem solchen Buskonflikt vielleicht
> die ganz Schaltung zusammenbrechen oder Chips kaputtgehen lässt.

ich berichtige:

.. auch verhindert dass durch zu viel Strom (der bei einem solchen
Buskonflikt vielleicht auftritt) die ganz Schaltung zusammenbricht
oder Chips kaputtgehen.

[Achim S. (Gast)]

Frickelfritze schrieb:
> Bei meiner Mikrokontroller-
> Implementierung werden ja auch nur schreibende Zugriffe auf den DDS
> gemacht.

Und wie sieht es mit Zugriffen auf die "anderen SPI Busteilnehmern im
Gerät" aus? Wie stellst du sicher, dass der DDS-Chip die nicht als 
(Schreib- oder Lese-)Zugriffe interpretiert, wenn du sein CS nicht 
entsprechend benutzt?

[Frickelfritze (Gast)]

Achim S. schrieb:
> Wie stellst du sicher, dass der DDS-Chip die nicht als
> (Schreib- oder Lese-)Zugriffe interpretiert, wenn du sein CS nicht
> entsprechend benutzt?

Das macht das CPLD das den Clock- und Datenkanal (sowohl MOSI als
auch MISO) maskiert bzw multiplext wenn ein anderer Busteilnehmer
angesprochen wird.

Anderherum gesprochen wird der DDS nur dann Clock und Daten bekommen
wenn sein CS aktiv ist - damit kanalisiert das CPLD Clock und Daten
einzig auf den DDS. Also ich behaupte mal dass das sehr sicher gelöst
ist, nicht so wie beim nackten Mikrocontroller wo der SPI CLock immer
an jedem Busteilnehmer wackelt ob angesprochen oder nicht.

[Achim S. (Gast)]

Frickelfritze schrieb:
> nicht so wie beim nackten Mikrocontroller wo der SPI CLock immer
> an jedem Busteilnehmer wackelt ob angesprochen oder nicht.

nichts für ungut, aber die Standard-Lösung mit nacktem Mikrocontroller 
und der Nutzung von CS funktioniert sehr zuverlässig in sehr vielen 
Schaltungen, während deine "sehr sichere Lösung" ja offenbar erst mal zu 
Buskonflikten geführt hat.

So wie ich deine aktuelle Beschreibung verstehe, hängt an der 
betrachteten MOSI und SCK Leitung also nur der DDS-Chip und das CPLD? 
Die "anderen SPI Busteilnehmer im Gerät" hängen also an physikalisch 
anderen Leitungen und sind von daher - aus Sicht dieser SPI-Verbindung - 
gar keine Busteilnehmer?

Dann sollte der AD9956 tasächlich auch ohne CS auskommen (d.h. CS fest 
auf GND) ohne dass es zu Buskonflikten kommt. Wenn du trotzdem welche 
siehst, läuft wohl etwas nicht ganz wie geplant. Vielleicht ein Glitch 
am CPLD-Ausgang wenn der "adressierte" SPI-Bus umgeschalten wird. Oder 
ein Signalintegritätsproblem mit CLK-Reversal, den man in deiner 
bandbreitenbegrenzten Messung nicht erkennt, bei dem ein Taktflanke vom 
IC als 2 Takte intepretiert wird. Oder eine unsaubere Behandlung von 
IO-Reset. Oder....

[Frickelfritze (Gast)]

Achim S. schrieb:
> "sehr sichere Lösung"

Ist sie auch, Daten und Clock kommen immer nur abhängig vom aktiven
Chip Select durch. Das ist für manche SPI Teilnehmer wie dem DDS
nicht wichtig wie du bereits erwähntest, für andere kann es dagegen
schon wichtig sein. Zudem ist dieser Mechanismus oft entscheidend um
(wie in meiner HF-Baugruppe) Noise der SPI Steuerung von empfindlichen
Schaltungsteilen fern zu halten.

Achim S. schrieb:
> So wie ich deine aktuelle Beschreibung verstehe, hängt an der
> betrachteten MOSI und SCK Leitung also nur der DDS-Chip und das CPLD?
> Die "anderen SPI Busteilnehmer im Gerät" hängen also an physikalisch
> anderen Leitungen und sind von daher - aus Sicht dieser SPI-Verbindung -
> gar keine Busteilnehmer?

Richtig, genau so wie ich es eingangs schon beschrieb - es ist eine
poin-to-point Verbindung ohne andere Teilnehmer.

Achim S. schrieb:
> Wenn du trotzdem welche
> siehst, läuft wohl etwas nicht ganz wie geplant.

Wie bereits erwähnt, sehe ich nicht den Vorgang im Datenblatt
dokumentiert unter welchen Bedingungen genau der DDS anfängt
Daten zu senden.