AD9833 funktioniert nur zufällig

[T. V. (ve_to)]

Hallo Leute,

ich habe ein Problem mit dem Ad9833. Er funktioniert nur sporatisch, was 
die Fehlersuche sehr erschwert. Die gesendeten Daten sehen laut 
Oszilloscope gut aus und sind immer die gleichen, auch der Chip-Select 
passt. Erst wenn ich dem Baustein meherere Resets hinter einander 
verpasse kann er die empfangenen Daten richtig interpretieren. Solange 
sich der Baustein noch nicht gefangen hat, kann zwar mit dem Baustein 
kommuniziert werden, aber auch hier werden alle Daten falsch 
interpretiert. Er gibt dann zum Beispiel eine kleine Gleichspannung von 
ca. 400mV , ein Sinus mit ca. 31kHz, ein undefiniertes 1MHz Signal oder 
auch gar kein Signal aus.

Wenn der Baustein sich einmal gefangen hat, funktioniert die 
Kommunikation und alles andere einwandfrei.

Angesteuert wird der AD9833 über einen SPI-Bus(Mode 2) des 
Mikrocontrollers NXP LPC1769.

Hatte hier jemand mal ein ähnliches Problem? Oder einen Tipp wie man so 
einen Fehler suchen kann?

Habe auch schon im Forum gesucht und ein Bausteintausch wie in:
Beitrag "Schwierigkeiten mit AD9833"
hat mir nicht geholfen.

Vielen Dank

[Karl M. (Gast)]

Hallo Torben,

bitte dokumentiere deine Schaltung vollständig, stelle auch Bilder von 
Aufbau ein und natürlich muss man auch das (vollständige) Steuerprogramm 
sehen.

Ich habe den AD9834, AD9851, AD9951 und AD9912 am laufen..

[T. V. (ve_to)]

Hier mal die Schaltung des Ad9833 bzw 9837 und der dazughöhrige Code.
Ablauf ist:

CAD9833::Init( );
-> reset auslösen, Singlanform wählen, Phase auf null setzten
CAD9833::Frequenz( uint32_t Frequenz );
-> Frequenz auf gewünschten Wert setzen

Über CAD9833::Work kann ich über eine Serielle Schnittstelle mit dem 
Baustein kommunizieren und Kommandos ausführen lassen.

[Pandur S. (jetztnicht)]

Die Chips von Analog Devices haben die Eigenschaft, dass das Datenblatt 
genauestens (!) durchgelesen werden muss. In diesem Fall das Kapitel der 
Kommunikation. Es kann an einem einzigen Wort liegen, das alles aendert. 
Ich wuerd nicht einfach davon ausgehen, dass SPIMode 2 richtig ist.

Kontrolliere die Kommunikation Flanke fuer Flanke, ob alle Sequenzen und 
Timings eingehalten werden.

[stefan (Gast)]

Ich tippe auch auf falsche initialisierung oder timings passen nicht.

[Arduinoquäler (Gast)]

Stolperfalle:

Im Datenblatt Seite 13 heisst es:

The SCLK can be continuous, or it can idle high or low between write 
operations. In either case, it must be high when FSYNC goes low (t11).
----------------------------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

[Pandur S. (jetztnicht)]

Bei AD Chips probiere ich gar nicht mehr erst, ob ein SPI Mode passt, 
sondern implementiere gleich eine Bitbang Kommunikation. Solange man 
nicht alle Milisekunden drauf zugreifen muss ist der Mehraufwand egal.