MISO verhaelt sich seltsam?

[Paul (Gast)]

Hi,

ich versuche gerade eine SPI Verbindung zwischen einem K60N512 und einem 
Gs1500M aufzubauen.
Es ist das erste mal das ich mich mit sowas beschaeftige.

Den SPI habe ich auf 1,2 MHZ mit CPOL = 0 und CPHA = 0 konfiguriert.

Auf dem angehaengten Bild sind MISO (Gruen) und  der MOSI (Gelb) zu 
sehen.
Mir ist aufgefallen, das der Slave immer nur auf das erste byte 
antwortet und dann nichts mehr macht ausser rauschen.

Ausserdem bin ich ein wenig verwirrt, warum der MOSI von low zu high 
wechselt und der MISO von high zu low.

Ist das normal oder ist es eine Einstellungssache?
Ist es ueberhaupt wichtig?

Ich bin dankbar fuer jede Hilfe, die ich kriegen kann!

[Jim M. (turboj)]

Plotte mal CS! Dein MISO zeigt nicht selektierten Slave, d.h. MISO ist 
nach dem 1. Byte hochohmig und MOSI koppelt kapazitiv/induktiv während 
der weiteren Übertragung ein.

Man sieht schön den langsam ansteigenden MISO, der von irgendeinem weak 
Pullup gezogen wird.

[Rainer U. (r-u)]

Hol Dir mal die Clock-Leitung mit dazu - so sieht man ja gar nicht, wo 
das Protokoll anfängt. Und bischen breiter in der Auflösung wäre auch 
gut.

Die Clock-Polarität ist schon entscheidend. Sie muss so sein, wie der 
Slave sie braucht (steht im Datenblatt), damit der Slave die Mosi auf 
der richtigen Clock-Flanke liest.

Wenn Du Dir also sicher bist, dass Dein gesendetes Protokoll stimmt, 
dann kannst Du die Antwort auswerten.

Das "Rauschen" ist wahrscheinlich nur "übersprechen" von der Mosi.

[Mike (Gast)]

Paul schrieb:
> Mir ist aufgefallen, das der Slave immer nur auf das erste byte
> antwortet und dann nichts mehr macht ausser rauschen.

Schalte auf deinem Oszi mal den Roman weg ;-)

Und zieh MISO mal z.B. mit einen (hochohmigen) Spannungsteiler auf 
VDD/2. Dann siehst du klarer, wann jemand die Leitung irgendwo hin zieht 
und wann die Leitung im Tri-State in der Luft hängt.

[Paul (Gast)]

Danke fuer die Hinweise, hat mir schon sehr geholfen.

Ich hab jetzt mal noch den CS und den Clock abgebildet.
Ausserdem hab ich auch noch ein Beispieldiagramm gefunden, wenn ich das 
richtig sehe, dann sind mein CS und mein Clock in Ordnung.

Im Datenblatt bin ich auf folgenden Satz gestossen.

"SPI chip select (MPSISI_CS0 or MPSI_CS1) signals frame each data word. 
If the chip select is required to remain asserted for multiple data 
words, then a GPIO pin should be used for the chip select instead of the 
SPI chip select signals"

Heisst das, ich muss bei jedem byte  den CS an und wieder aus machen?


Mike schrieb:
> Und zieh MISO mal z.B. mit einen (hochohmigen) Spannungsteiler auf
> VDD/2. Dann siehst du klarer, wann jemand die Leitung irgendwo hin zieht
> und wann die Leitung im Tri-State in der Luft hängt.

Ich bin leider nur ein doofer Informatikstudent und weiss nicht wie das 
geht :-D

[Mike (Gast)]

Paul schrieb:
> Ich bin leider nur ein doofer Informatikstudent und weiss nicht wie das
> geht :-D

Ganz einfach mit zwei Widerständen (z.B. 100kΩ)

   VDD -- 100k --+-- 100k -- Gnd
                 |
              MISO/Oszi

[EFA (Gast)]

Die Pause nach dem 8. clk erscheint auch etwas zu kurz.

[karl (Gast)]

Hi,
das Datenblatt würde ich so interpretieren:
das heisst du musst im Datenblatt des Slaves schauen ob dein Slave bei 
einem Transfer von mehreren Bytes das Chip Select die ganze Zeit über 
aktiv haben will oder ob er nach jedem Byte wieder inaktiv werden soll.
Im ersten Fall musst du den Chip select des Slaves an einen GPIO des 
Masters hängen und per Software steuern, im 2. Fall dierekt vom CS 
Ausgang des Masters.

LG Karl

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

Irgendwie verschluckt sich die CLK Leitung und genau dann rastet der 
MISO aus.

Wie sieht denn der Code vom Takt erzeugenden Przessor aus und welcher 
ist es?
Schalteste ausversehen die Clockpolarity vom SPI um während der 
Übertragung?

[123 (Gast)]

Auf clockZoom.jpeg sieht man ja deutlich, dass du die Constraints bzgl. 
der Clock nicht einhältst. Das heißt das Problem liegt bei der 
CLK-Erzeugung in deinem Controller.

[Paul (Gast)]

Vielen Dank fuer die Hinweise!

Ich habe die Verbindung nun hinbekommen. Es lag am Chipselect, dieser 
muss naemlich alle 8bits einmal kurz aktiv werden.

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

Sicher nicht, durch das CS Umschalten verhinderst du sicher nur den 
Clockskew.
Guck also nochmal nach was beim Takerzeiugen des Prozessors schiefgeht.

[Paul (Gast)]

Hmm also so sieht es jetzt aus.

Am Clock hab ich auch was geandert, aber das war noch vor dem CS . 
Deswegen hab ich das jetzt nich als Ursache erkannt.

Den Code fuer den CLK habe ich von

SPI2_BASE_PTR->CTAR[0] = (SPI_CTAR_FMSZ(7) | SPI_CTAR_BR(4)  | 
SPI_CTAR_PBR(2) | SPI_CTAR_DBR_MASK );

zu

SPI2_BASE_PTR->CTAR[0] = (SPI_CTAR_FMSZ(7) | SPI_CTAR_BR(4)  | 
SPI_CTAR_PBR(2) | SPI_CTAR_DBR_MASK | SPI_CTAR_CSSCK(3) 
|SPI_CTAR_PASC(2)  );

geaendert.

Eine Beschreibung des Register kannst du hier nachlesen
http://www.freescale.com/files/32bit/doc/ref_manual/K60P144M100SF2RM.pdf?fpsp=1&WT_TYPE=Reference%20Manuals&WT_VENDOR=FREESCALE&WT_FILE_FORMAT=pdf&WT_ASSET=Documentation 
(Seite 1408)