MOSI-Pegel viel zu niedrig, aber warum?

[Florian K. (f-kae)]

Hallo zusammen,

ich versuche über SPI mit einem Sensor zu kommunizieren.
Leider bekomme ich keine Antwort von diesem und habe daraufhin mit einem 
Oszilloskop Clock und MOSI Leitung geplottet(siehe Bild).

Das ganze läuft auf einem STM32F407VGT welcher mit 3V betrieben wird.
Ich versuche über den SPI3port -> "0x88" zu schicken, was auch gerade so 
noch im Bild erkennbar ist.

Auf dem Bild erkennt man, dass die Clockleitung wie erwartet mit ca 
3V-Signalen arbeitet, aber was ich nicht verstehe ist, warum das 
MOSI-Signal eine Differenz zwischen logisch "1" und logisch "0" von ca 
200mV hat.
Ich habe die Anschlußklemme auch mal umgesteckt um sicher zu gehen, dass 
es nicht am Oszi liegt.
Die Clock-Leitung schaltet auch nach dem Tausch(der Klemmen) zwischen 0V 
und 3V!!

Kann sich jemand erklären wo das Problem liegen könnte?

Ich bin noch recht neu in der Thematik und weiß nicht, ob die Frage 
schon so beantwortbar ist oder ob noch mehr CODE oder Schaltplan-Details 
benötigt werden. Um eine unnötige Informationsflut zu vermeiden, sende 
ich erst einmal nur den Screenshot mit.

Viele Grüße und einen schönen Samstagabend :)
Florian

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

Ohne wenigstens einen Software Auszug oder den Schaltplan kann man nur 
spekulieren.
*MOSI auf Ausgang geschaltet?
*Kollidieren da evtl. 2 Ausgänge?
*Schaltest du da vllt. nur den Pullup an und aus?

[(prx) A. K. (prx)]

Florian K. schrieb:
> Die Clock-Leitung schaltet auch nach dem Tausch(der Klemmen) zwischen 0V
> und 3V!!

Die 3V sehe ich, aber die 0V sind eher 0,3V. Für eine unbelastete 
CMOS-Leitung ist das etwas ungewöhnlich.

> schon so beantwortbar ist oder ob noch mehr CODE oder Schaltplan-Details
> benötigt werden.

Schaltplan auf jeden Fall schon.

> Um eine unnötige Informationsflut zu vermeiden, sende
> ich erst einmal nur den Screenshot mit.

Das ist doch mal eine wirklich kreative Begründung an Stelle des 
üblichen "Plan habe ich im Kopf und bis zu faul ihn zu zeichnen". ;-)

[Michi (Gast)]

Du hast verm. den MOSI Pin mit anderer Hardware beschaltet, die das MISO 
Signal zu stark belastet.

[Wolfgang (Gast)]

... oder der MOSI ist abgeschossen.

Da wäre es gut, den MOSI zu isolieren, i.e. alle Leitungen davon zu 
trennen - wirklich alle - und noch mal zu gucken, ob dann ein 
vernünftiger Pegel rauskommt.

[Florian K. (f-kae)]

Hallo,

ok erst einmal Entschuldigung für die Unvollständigkeit, ich habe nun 
Schaltplan und CODE eingefügt.

Ich nutze den SPI3-Port mit dem nichts anderes verbunden ist als auf dem 
Schaltplan zu erkennen.

Ich nutze zum programmieren eine Bibliothek (XPCC). An dieser Stelle 
sollte es keine Probleme geben, da ich bereits auf dem STM32F4-Discovery 
den SPI-Port damit betrieben habe (ohne Probleme).

Was ich nun schon festgestellt habe ist, dass ich leider beim Package 
(des LIS3LV02DL) einen Fehler eingebaut habe. Daher habe ich alle 
Leitungen zum Sensor getrennt.

Das Problem bleibt weterhin bestehen.

[Jannis C. (kabelwurm)]

Tastkopf richtig eingestellt? Sowohl am Oszi als auch am Kopf selber? 
Nicht das der noch auf 1:10 steht, das Oszi aber auf 1:1 eingestellt 
ist? Das würde genau passen, da 0,3V ablesbar sind, das Zehnfache, 3V 
das ist, was du erwartest.
Gruß Jannis

[T.Roll (Gast)]

Florian K. schrieb:
> SCH_1.png
> SCH_2.png

Ohne die Diskussion stören zu wollen - du weißt, dass mit in Eagle 
Verbindungen zwischen Bauelementen mit den Befehlen Wire und Bus 
zeichnen kann?
So sucht man sich tot nach zueinandergehörigen Labels. Aber es ist 
natürlich schneller, die Bauteile "hinzuklatschen" und die Signalnamen 
ranzuschreiben.

[Florian K. (f-kae)]

Ja anfangs war das meine Vermutung(Hoffnung) aber wie ich schon ganz 
oben versucht habe anzudeuten:

>Ich habe die Anschlußklemme auch mal umgesteckt um sicher zu gehen, dass
>es nicht am Oszi liegt.
>Die Clock-Leitung schaltet auch nach dem Tausch(der Klemmen) zwischen 0V
>und 3V!!

Ich habe aber auch nachgeschaut, es sind sowohl an den Tastköpfen als 
auch im Menü des Oszis alle Einstellungen auf 1/10.

[sebihepp (Gast)]

Ich sehe auch nirgends Pullups für den SPI Bus.

[Florian K. (f-kae)]

T.Roll schrieb:
> Ohne die Diskussion stören zu wollen - du weißt, dass mit in Eagle
> Verbindungen zwischen Bauelementen mit den Befehlen Wire und Bus
> zeichnen kann?
> So sucht man sich tot nach zueinandergehörigen Labels. Aber es ist
> natürlich schneller, die Bauteile "hinzuklatschen" und die Signalnamen
> ranzuschreiben.

Ja es ist mir bekannt: Für die Betrachtung des Schaltplans ohne Eagle, 
gebe ich zu ist es etwas aufwendiger(zusammengehörendes zu finden), aber 
mit Eagle finde ich es so deutlich übersichtlicher und angenehmer.
Ich hatte gehofft, dass die beiden Ausschnitte nicht so unübersichtlich 
sind, dass man auch ohne Eagle innerhalb von 2-3 Minuten alle 
Verbindungen erkennt.

Wolfgang schrieb:
> ... oder der MOSI ist abgeschossen.
>
> Da wäre es gut, den MOSI zu isolieren, i.e. alle Leitungen davon zu
> trennen - wirklich alle - und noch mal zu gucken, ob dann ein
> vernünftiger Pegel rauskommt.

Ich hoffe immernoch, dass ich da irgendwie drumherum komme. Aber wenn es 
keine anderen Vorschläge gibt muss ich wohl in den sauren Apfel beißen 
:(

[Florian K. (f-kae)]

sebihepp schrieb:
> Ich sehe auch nirgends Pullups für den SPI Bus.

Ähm, werft mit Steinen nach mir wenn ich das falsch verstanden habe, 
aber ich dachte Pull-Ups brauche ich nur bei I2C. Von Pull-Ups ist auch 
in keinem einzigen Datenblatt der Sensoren die rede!

[(prx) A. K. (prx)]

Florian K. schrieb:
> Ähm, werft mit Steinen nach mir wenn ich das falsch verstanden habe,
> aber ich dachte Pull-Ups brauche ich nur bei I2C. Von Pull-Ups ist auch
> in keinem einzigen Datenblatt der Sensoren die rede!

An die CS-Leitungen von SPI-Slaves hängt man gerne eher hochohmige 
Pullups, damit die Slaves sich nicht angesprochen fühlen, wenn die 
Leitungen bis zur Initialisierung der entsprechenden Pins vom Controller 
floaten. Ganz besonders wenn mehrere SPI-Slaves an einem Master hängen.

Deinem Code ist zu Initialisierung und Zustand der SPI-Leitungen nichts 
zu entnehmen.

[Florian K. (f-kae)]

A. K. schrieb:
> Deinem Code ist zu Initialisierung und Zustand der CS-Leitungen nichts
> zu entnehmen.

Ohh, ja richtig, ich beschäftige mich noch nicht sehr lange mit der 
Thematik und hatte gedacht, um ein Signal auf die MOSI Leitung zu 
bekommen sind die CS_Leitungen erst einmal unrelevant. Aber auch wenn 
ich alle CS_Leitungen auf HIGH setzte, habe ich das selbe Problem.

[(prx) A. K. (prx)]

Mach ein frisches leeres Programm. Definierte alle SPI3 CS-Pins als 
Ausgang und setze sie auf 1, also inaktiv. Totschleife. Sonst nichts. 
Die MISO Leitung müsste nun floaten, weil kein Slave angesprochen wird.

Verifiziere mit Messgerät, dass die CS Leitungen wirklich alle auf VCC 
liegen.

Nun stellst du das Messgerät auf Strommessung ein und verbindest es am 
einen Ende über einen Widerstand 1K mit MISO, am anderen Ende 
nacheinander mit VCC und GND. Wenn dabei Strom fliesst, dann hast du 
verloren und solltest dir deine Platine mal ganz genau ansehen.

[(prx) A. K. (prx)]

Was noch nützlich sein kann: Die Datasheets aller SPI-Slaves 
durchforsten, ob irgendwas beim SPI besonders ist. Da können auch welche 
dabei sein, die schon Pullups an CS intern dran haben.

Und gleich beim ersten davon wurde ich fündig: Der BMA180 hat ein 
kombiniertes I2C/SPI. Bei inaktivem CS (hat internen Pullup) reagieren 
SDI/SCK als I2C. Der Chip ist also bei inaktivem CS keineswegs still und 
leise, sondern reagiert auf SPI-Traffic, der ihn nichts angeht.

Man kann diese Doppelfunktion auch per Software abschalten, wie auch im 
Datasheet empfohlen. Nur könnte man dabei in ein Henne/Ei Dilemma 
laufen, wenn noch so ein Kollege dabei ist.

[(prx) A. K. (prx)]

Beim LSM330DLC sieht es ähnlich aus. Die Dinger scheinen beim SPI nicht 
wirklich für Betrieb mit mehreren Slaves an einem SPI konzipiert zu 
sein.

[Florian K. (f-kae)]

Vielen Dank A.K. (prx).

Ich wusste nicht das diese Funktion Probleme hervorrufen würde :/, jetzt 
frage ich mich allerdings wie ich auf den BMA180 zugreifen kann um I2C 
zu deaktvieren.
Im Register "high_dur" gibt es ein Bit "dis_i2c" um dies zu 
deaktivieren.
Aber ich bekomme ja garkeine Kommunikation hin.

edit: Oh ok, das heißt ich muss beide Sensoren von diesem SPI trennen 
und einzelen mit einem eigenen BUS betreiben?

edit2:
Bzw kann ich zum Beispiel den LSM330 an einen anderen SPI-Port klemmen 
und beim  BMA180 als erstes CS auf LOW, dann I2C deaktivieren und danach 
auch mit allen anderen Sensoren an diesem Bus kommunizieren?

[(prx) A. K. (prx)]

Bei nur einem solchen Kombinierer pro SPI-Bus, mit softwareseitig 
abschaltbarem I2C, ist es relativ einfach: Den als erstes ansprechen. 
Bei mehreren muss man drauf hoffen, dass nicht zufällig ein Pattern 
auftritt, dass der Slave als an ihn adressiertes I2C versteht. Die 
Wahrscheinlichkeit eines Konflikts ist nicht sehr hoch.

Mach erst einmal die erwähnte Messung.

Problematische Geräte an eigene SPIs hängen oder per Gatter/Muxer 
abkoppeln. Ist ja mehr als ein SPI da. Ich habe auch nicht alle Slaves 
durchgesehen, nur die linken 3 und von denen ist nur einer völlig 
sauber.

[Florian K. (f-kae)]

So, ich habe nun eine Messung wie vorgeschlagen gemacht:

GPIO__OUTPUT(BMA180_CS, D, 6);
GPIO__OUTPUT(HMC5983_CS, D, 2);
GPIO__OUTPUT(LIS3LV02DL_CS, D, 0);
GPIO__OUTPUT(L3GD20_CS, D, 5);
GPIO__OUTPUT(MPL115A1_CS, B, 5);
GPIO__OUTPUT(LSM330DLC_ACC_CS, A, 8);
GPIO__OUTPUT(LSM330DLC_GYRO_CS, C, 9);


static bool
initClock()
{
  
  xpcc::stm32::Clock::enablePll(xpcc::stm32::Clock::PLL_HSI, 8, 168);
  return xpcc::stm32::Clock::switchToPll();
}


MAIN_FUNCTION
{
  initClock();



  xpcc::stm32::SysTickTimer::enable();

  BMA180_CS::setOutput(true);
  HMC5983_CS::setOutput(true);
  LIS3LV02DL_CS::setOutput(true);
  L3GD20_CS::setOutput(true);
  MPL115A1_CS::setOutput(true);
  LSM330DLC_ACC_CS::setOutput(true);
  LSM330DLC_GYRO_CS::setOutput(true);


  typedef xpcc::stm32::SpiMaster3 MySpi3;
  MySpi3::initialize(MySpi3::MODE_0, MySpi3::PRESCALER_256);
  MySpi3::configurePins(MySpi3::REMAP_PC10_PC11_PC12);



  while (1)
  {

  }

  return 0;
}

BMA,L3G,HMC,LIS,LSM_A & LSM_G sind alle 3V allerdings ist die CS-Leitung 
von dem MPL115A1 auf 2,1V anstatt 3V!!! Verstehe ich ehrlich gesagt 
nicht!

Dann habe ich eine Strommessung von MISO über 1K nach:

GND: 0,8mA
3,3V: -2mA

Nach einem Neustart sind nun alle CS-Leitungen auf 3V und ich messe 
keinen Strom über die MISO-Leitung, weder zu GND noch zu 3,3V.

edit:
Meintest du mit "softwareseitigem" abschalten der I2C-Funktionalität, 
eben die Variante über das entsprechende Register I2c zu deaktivieren?
Beim LSM habe ich diese Funktion beim ersten drüberschauen nicht 
gefunden.

Schon einmal vielen vielen dank an alle. Das Forum ist echt super und 
hat mir nicht zum ersten mal weitergeholfen! :)

edit2:
Dummerweise ist der L3G auch über I2C ansprechbar, den LIS habe ich aus 
anderen Gründen sowieso schon "entfernt", dieser wäre sonst auch noch 
über I2C ansprechbar gewesen.

[mermax (Gast)]

Hallo!

Das I2C-SPI-Problem hatte ich auch mal. Kann man gut mit einem Gatter 
behebn: Siehe Figure36 im Datenblatt.

[(prx) A. K. (prx)]

Florian K. schrieb:
> BMA,L3G,HMC,LIS,LSM_A & LSM_G sind alle 3V allerdings ist die CS-Leitung
> von dem MPL115A1 auf 2,1V anstatt 3V!!! Verstehe ich ehrlich gesagt
> nicht!

Da wirds interessant.

> Dann habe ich eine Strommessung von MISO über 1K nach:
> GND: 0,8mA
> 3,3V: -2mA

Was nicht der Fall sein sollte, wenn alle CS inaktiv sind.

[Florian K. (f-kae)]

A. K. schrieb:
>> Dann habe ich eine Strommessung von MISO über 1K nach:
>> GND: 0,8mA
>> 3,3V: -2mA
>
> Was nicht der Fall sein sollte, wenn alle CS inaktiv sind.

Wie ich noch dazu geschrieben hatte, dieser Fall trat nur nach dem 
Auto-Reset nach dem Programmieren auf. Nach einem Neustart ist immer 
alles OK, also alle CS Leitungen auf 3V und es fließt kein Strom.

Gibt es denn jetzt eine Möglichkeit das Problem ohne zusätzliche 
Hardware zu lösen?
Es wurde von softwareseitiger I2C-Deaktivierung gesprochen. Mir leuchtet 
leider noch nicht ein, wie ich das realisieren kann.

Diesen Kommentar meinte ich Konkret:

>Bei nur einem solchen Kombinierer pro SPI-Bus, mit softwareseitig
>abschaltbarem I2C, ist es relativ einfach: Den als erstes ansprechen.
>Bei mehreren muss man drauf hoffen, dass nicht zufällig ein Pattern
>auftritt, dass der Slave als an ihn adressiertes I2C versteht. Die
>Wahrscheinlichkeit eines Konflikts ist nicht sehr hoch.

[(prx) A. K. (prx)]

Florian K. schrieb:
> Es wurde von softwareseitiger I2C-Deaktivierung gesprochen. Mir leuchtet
> leider noch nicht ein, wie ich das realisieren kann.

Das geht nur dort wo es geht. ;-)

Wenn ein Slave mit kombiniertem I2C/SPI an einem SPI-Bus sitzt, bei dem 
I2C abschaltbar ist, dann kann man ohne Trennungsmassnahmen noch weitere 
reine SPI-Slaves zusätzlich dranhängen. Aber nur solche.

[(prx) A. K. (prx)]

Florian K. schrieb:
> Wie ich noch dazu geschrieben hatte, dieser Fall trat nur nach dem
> Auto-Reset nach dem Programmieren auf.

Was wird dabei resettet? Nur der Prozessor, oder auch die Slaves? Die 
Slaves haben kein Reset und das Programmierinterface startet zwar den 
Prozessor neu, aber der Rest des Systems krieg nichts davon mit.

> Nach einem Neustart ist immer
> alles OK, also alle CS Leitungen auf 3V und es fließt kein Strom.

Neustart == Power-Up? Dann werden die Slaves resettet und geben Ruhe.

Du solltest aber vor einem Neudesign erst einmal die beiden 
Pegelprobleme abschliessend klären. Das mit 2,1V, und das weiter oben 
erwähnte mit den 0,3V.

Zu den 0,3V, die wahrscheinlich dem Treiberkonflikt zuzurechnen sind: 
Zieh SCK per Pullup-Widerstand auf 1. Erweitere ein Minimal-Testprogramm 
so, dass es nach einem Power-Up genau und nur an MOSI wackelt. Also ohne 
SPI, direkt per GPIO. Das ist I2C-Slaves bei SCK=1 egal. Da dann wie du 
eben beschrieben hast, kein Treiberkonflikt auftritt, sollte es wirklich 
GND/VCC sein, nicht 0,3V daneben.

Und die 2,1V solltest du auch erst einmal klären. Dazu lässt sich schwer 
etwas sagen, da musst du wohl mal deine Platine genau untersuchen.

[(prx) A. K. (prx)]

PS: Zu den 2,1V: Dessen CS kommt von einem anderen Port als alle anderen 
CS-Signale.

PPS: Bei einem Neudesign mit Muxer oder Trenn-Gatter drauf achten, dass 
alle I2C-Eingänge der Slaves beim Power-Up immer schön mit 1 zur Welt 
kommen, auch schon bevor der µC wach ist. Ggf. Pullups einfügen. Oder 
gleich I2C statt SPI verwenden.

[Florian K. (f-kae)]

OK, es gab tatsächlich ein Problem mit dem MPL, der PLatinenhersteller 
hat mir disen leider falsch herum montiert. Nachdem ich alle 
Leiterbahnen zu diesem Sensor zerkratzt habe bekomme ich endlich ein 
sauberes Signal allerdings habe ich die SCK und MOSI Pins als normale 
GPIOs initialisiert und auf SCK dauerhaft ein HIGH und den MOSI-Pegel 
wie vorgeschlagen alle 20ms von HIGH auf LOW getoggelt.

[Florian K. (f-kae)]

OK zum Abschluß habe ich noch eine Frage:

Ich habe nun am SPI-BUS nur noch den BMA180 und den HMC.

Ich habe beim BMA180 I2C deaktiviert und bin nun von der MISO-Leitung 
etwas irritiert.

Ich habe als Befehl gesendet, dass das ID-Register (des BMA180) 
ausgelsen werden soll, welches 0x03 beinhaltet. Die Information scheint 
auch anzukommen, allerdings verstehe ich nicht warum die MISO Leitung im 
"Normalfall" (also ohne Senden Befehl) einen Pegel von ca. 2V hat.
Ich habe vorher noch nie Pegel von SPI-Signalen gesehen und weiß daher 
nicht ob das so in Ordnung ist, oder auch noch ein Problem darstellt.

VIELEN Vielen Dank auf jeden Fall an alle die mir geholfen haben und vor 
allem an - A. K. (prx) -

[(prx) A. K. (prx)]

Schau dir mal Fig 17 an. Der Sensor schaltet den SDO erst ein, wenn er 
die Adresse hat, also nach 8 Bits. Davor floatet der Pin und genau das 
siehst du hier.

Allerdings favorisiert der Sensor einen anderen SPI-Modus als du 
eingestellt hast. Mit SCK anfänglich 1, nicht 0.

[Florian K. (f-kae)]

Danke!

Erkenne ich auch an Figure 17 über die gestrichelte senkrechte Linie am 
Anfang, das der Modus für SPI auf "sample on falling edge" eingestellt 
werden muss?
Muss ich zusätzlich auch noch SCK invertieren da, in Figure 17 SCK auf 
HIGH anfängt und dann das erste sample auf der ersten fallenden Flanke 
nimmt?

Also MODUS: SCK inverted, sample on falling edge

edit: Sinnvoll erscheint mir nun doch eher:
SCK inverted, sample on rising edge

[(prx) A. K. (prx)]

Du musst nur die Doku vom Controller oder dessen Lib lesen.

[Florian K. (f-kae)]

Wie ich den Modus in der LLib wechsel weiß ich.

Ich habe mich nur gefragt wodran ich das genau ablesen kann, welchen 
Modus der Sensor bevorzugt.

Im Datenblatt steht: "Data on SDI is latched by BMA180 at SCK rising 
edge"

daraus folgere ich also das der Modus:" sample on rising edge" richtig 
ist?!

Ich denke jetzt verstehe ich es langsam.
Nochmals vielen Dank, vor allem für die Gedult mit einem "Anfänger" in 
der Thematik! :)