Moin Moin,
ich habe einen STM32F303 und einen MAX31855 der via SPI Daten ausgeben
soll, sobald man ein Clock Signal ausgibt.
Allerdings kommt bei mir genau "NICHTS" an.
CS mit OSZI gecheckt, passt. Zieht sauber auf LOW und dann wieder auf
HIGH. SCK macht saubere Pulse, nach jeweils 8 Pulsen ist eine kleine
Pause zu sehen. Ich verwende den Befehl (HAL_SPI_Receive(&hspi2, buffer,
4, 1000)); und der STM32 ist als Full Duplex Master konfiguriert.
Die Einstellungen zu CPOL und CPHA sind identisch mit denen im Git
Ordner.
Datenrate beträgt unter 1Mbit/s.
https://github.com/SimpleMethod/STM32-MAX31855
Ich verwende diese Lib aktuell NICHT, ich gehe den "manuellen" Weg:
1
uint8_tbuffer[4];
2
3
CS_LOW
4
HAL_SPI_Receive(&hspi2,buffer,4,1000)
5
CS_HIGH
6
7
....bufferverarbeiten
Aber es kommt nichts an. Einen 2K2 Pull-Up gegen 3.3V habe ich an MISO
angeschlossen, jedeoch sieht das Signal auf dem OSZI identisch mit dem
CS aus. Es geht auf LOW und nach den Clock Pulsen wieder auf High. Also
so, also wenn der MAX die Leitung einfach auf LOW zieht.
Über die Lib bin ich auf diesen Beitrag gestoßen, der soll allderdings
nur gelten wenn man den Mode "Receive_Only_Master" nutzt.
https://github.com/SimpleMethod/STM32-MAX31855/issues/1
Darauf hin habe ich den Pull-Down an SCK aktiviert, da Signal beginnt
jetzt bei LOW (vor dem Pull Down war es immer auf high gezogen) und es
sieht sehr gut aus.
Trotzdem kommen keine Daten und ich bin so langsam mit meinem Latein am
Ende. Muss ich wirklich jedes mal das SPI resetten und auf "Busy"
checken? Das kann doch nicht im Sinne des Erfinders sein.
Der auf eevblog verlinkte Beitrag hilft mir leider auch nicht wirklich
weiter:
https://www.eevblog.com/forum/microcontrollers/stm32-spi-slave-inconsistent/
Habt ihr noch eine Idee was man machen könnte?
Ach ja die, MAX31855 sind kleine Fertig-Module von Adafruit, ich hoffe
mal da sind keine Fälschungen drauf.
Beste Grüße
jens
jens schrieb:> Ich verwende diese Lib aktuell NICHT, ich gehe den "manuellen" Weg:
Da müsstest du schon zeigen was du sonst noch alles "manuell"
machst. Da können beliebig Fehler drin stecken. Entweder
den ganze Code zeigen oder das wird ein ewiges Suchrätsel
bleiben. Deine Schaltung kann ja auch fehlerhaft sein, oder?
Nein, das kann natürlich nicht sein .....
jens schrieb:> Darauf hin habe ich den Pull-Down an SCK aktiviert
Was soll das Rumhantieren mit Pulls? Welches Wissen reitet dich
dazu? Du brauchst an SPI Signalen keine Pull-Widerstände, weder
intern noch extern.
jens schrieb:> da Signal beginnt> jetzt bei LOW (vor dem Pull Down war es immer auf high gezogen)
Ein Pull-Widerstand darf ein SPI Signal nicht verändern sonst
ist was an der Konfiguration faul.
jens schrieb:> Der auf eevblog verlinkte Beitrag hilft mir leider auch nicht wirklich> weiter:
Ja, aber das Erlernen des Umgang mit der Technik würde was
helfen. Einfach verstehen was man tut ....
jens schrieb:> Der auf eevblog verlinkte Beitrag hilft mir leider auch nicht wirklich> weiter:
Denn dort wird von einem STM32 Controller gesprochen der als
Slave konfiguriert wird. Du hast keinen Slave sondern einen
Master. Der Master will was von einem Slave, das ist dein MAX31855.
jens schrieb:> Ach ja die, MAX31855 sind kleine Fertig-Module von Adafruit
Wie sind die denn angeschlossen? Gibts da ein Foto davon? Hast du ein
Thermoelement dran? Hat der Max seine Versorgung und ist der Max-GND mit
dem µC-GND verbunden?
> CS mit OSZI gecheckt, passt. Zieht sauber auf LOW und dann wieder auf> HIGH. SCK macht saubere Pulse, nach jeweils 8 Pulsen ist eine kleine> Pause zu sehen.
Passt das erzeugte CS und SCK Timing zu dem, was das Datenblatt
verlangt?
Wie hast du die Tastköpfe angeschlossen? Hast du direkt am Max gemessen?
Denn nur das, was dort direkt am Max-GND und CS und SCK passiert,
interessiert den Max...
Und wenn der CS und SCK soweit passen mach doch mal die Verbindung des
SO vom Max zum µC ab und miss nur den SO Ausgang des Max.
Config SPI komplett über CubeIDE, siehe Bild.
Anbei noch zwei Bilder von MOSI (blau) und SCK gelb. Einmal mit internem
PullUp an MOSI, einmal ohne.
jens
jens schrieb:> Anbei noch zwei Bilder von MOSI (blau) und SCK gelb. Einmal mit internem> PullUp an MOSI, einmal ohne.
Völlig irrelevant was MOSI macht wenn keine Datenphase aktiv
ist. In beiden Fällen ist MOSI in der aktiven Phase low was
auf eine gesendete Null (vier Nullen) hindeuted. Und das ist
ja auch OK, denn der Receive-Aufruf im HAL wird - um Daten zu
empfangen - Nullen senden.
Nichts Verdächtiges bis dahin .....
beo bachta schrieb:> Völlig irrelevant was MOSI macht wenn keine Datenphase aktiv> ist.
Aber wie aktiviere ich diese Phase denn? Nach meinem Verständnis doch
mit dem senden des CS LOW + CLOCK Signal?
beo bachta schrieb:> Nichts Verdächtiges bis dahin .....
Wichtiger wäre also mit dem Oszilloskop zu sehen was auf
der MISO Leitung daherkommt. Dort müsste - da man den Chip
ja nicht weiter kommandieren kann und muss - immer irgend-
welche Daten abweichend von Null daherkommen.
jens schrieb:> Anbei noch zwei Bilder von MOSI (blau) und SCK gelb. Einmal mit internem> PullUp an MOSI, einmal ohne.
Dir ist aber schon klar dass dein MAX31855 keinen MOSI-Pin hat?
Und der MISO Pin deines Controllers muss mit Pin7 (SO, Slave Out)
deines MAX31855 verbunden sein? Sonst wirst du nie Daten empfangen
können.
Dabei kommt der Gedanke auf dass du überhaupt nicht weisst was
MOSI und MISO bedeuten da du Eingangs beharrlich von MOSI
sprichst der in diesem Zusammenhang wenig Bedeutung hat.
Zum Anderen kommen hier natürlich wilde Spekulationen auf da du
nicht dokumentierst was genau du mit wem verbunden hast.
beo bachta schrieb:> Dabei kommt der Gedanke auf dass du überhaupt nicht weisst was> MOSI und MISO bedeuten
Sieht glatt so aus. Nochmal kurz:
* SO (Serial Out) vom Max geht an den MISO (Master In, Slave Out)
vom STM
* SCLK vom STM an den SCK des Max
* der CS passt ja hoffentlich...
Wie ich schon schrieb:> mach doch mal die Verbindung des SO vom Max zum µC ab und miss nur den> SO Ausgang des Max.
Dort am SO kommen nämlich die Daten des Max heraus.
jens schrieb:> Habt ihr noch eine Idee was man machen könnte?
Die grundlegend beste Idee hier wäre tatsächlich gewesen, einen
Schaltplan statt Prosa zu posten. Da hätte man so triviale Fehler sofort
gesehen.
beo bachta schrieb:> keinen MOSI-Pin hat
Ja, du hast Recht. Ich spreche immer von MOSI, bin aber am DO des MAX
dran, der ist verbunden mit meinem MISO.
Lothar M. schrieb:> Und wenn der CS und SCK soweit passen mach doch mal die Verbindung des> SO vom Max zum µC ab und miss nur den SO Ausgang des Max.
Ich habe das gerade mal probiert und siehe da, es kommen Daten an!(sehe
ich auf dem Oszi). Sobald ich die Verbindung zu MISO wieder herstelle,
sieht es wieder aus wie in Bild 2. Keine Daten (PullUp an MISO ist
deaktiviert, aber der spielt ja keine Rolle wie ich gelernt habe).
Gibt es beim SPI noch etwas in der Config zu beachten?
Erst mal danke für eure Anteilnahme an meinem Problem :).
jens
jens schrieb:> Ich habe das gerade mal probiert und siehe da, es kommen Daten an!(sehe> ich auf dem Oszi). Sobald ich die Verbindung zu MISO wieder herstelle,> sieht es wieder aus wie in Bild 2. Keine Daten
Dann ist dein MISO Pin falsch konfiguriert.
Zeige deine Initialisierung!
jens schrieb:> Ich habe das gerade mal probiert und siehe da, es kommen Daten an!(sehe> ich auf dem Oszi).
Naja, schon wieder unsauber: es kommen keine Daten an (die Verbindung
ist ja aufgetrennt), sondern die Daten gehen am Max raus.
> Gibt es beim SPI noch etwas in der Config zu beachten?
Da scheint irgendwie der Pin falsch konfiguriert. Oder du verwechselst
immer noch MISO und MOSI...
Initialisiere mal die 4 Bytes im Buffer nicht mit 0, sondern mit
unterschiedlichen Werten wie z.B. 0x11, 0x22, 0x44 und 0x88, damit sich
am MOSI was ändert.
jens schrieb:> Sobald ich die Verbindung zu MISO wieder herstelle,> sieht es wieder aus wie in Bild 2.
Letzte Fehler-Hoffung: du hast eventuell einen falschen
Pin für MISO verwendet der dann deinen Datenstrom vom
MAX31855 kurzschliesst.
jens schrieb:> Gibt es beim SPI noch etwas in der Config zu beachten?
Ich sehe gerade dass man SPI in CubeMX auf acht verschiedene
Arten konfigurieren kann. Der Einfachheit halber würde ich
"Full-Duplex Master" wählen. Das funktioniert auf jeden Fall.
Alle Slave-Versionen funktionieren jedenfalls nicht.
beo bachta schrieb:> Dann ist dein MISO Pin falsch konfiguriert.> Zeige deine Initialisierung!
siehe spi.c im Anhang.
Lothar M. schrieb:> Da scheint irgendwie der Pin falsch konfiguriert. Oder du verwechselst> immer noch MISO und MOSI...
Nein, ich bei MISO und MOSI bin ich mir sicher. Wir reden vom MISO PIN
von SPI2 am STM32F303CC, in meinem Fall Pin PB14 (Pin27 am LQFP48).
Aber ja, ich denke auch das der Pin noch falsch konfiguriert ist.
Kurzschlüsse sind jedenfalls keine drauf (>300K zu den Nachbarpins, VCC
und GND)
jens
beo bachta schrieb:> Zeige auch die GPIO-Initialisierung.
siehe gpio.c im Anhang. Der CS_MAX31855 Pin ist nicht der, den ich
verwende. Es ist auf der Platine noch ein MAX31855 vorgesehen, aber
aktuell nicht verbaut. Der CS um den es hier geht ist SPI2_CS!
jens schrieb:> Aber ja, ich denke auch das der Pin noch falsch konfiguriert ist.
Da werden wir wohl noch mal einen Blick in deine SPI.h und GPIO.h
werfen müssen. Da überkreuzt sich doch irgendwas. Evtl. sind
auch die Pin-Bezeichnungen nicht eindeutig.
jens schrieb:> siehe gpio.c
Und warum machst du dein dazu geschriebens GPIO Init nicht genauso wie
es dir STM vormacht und nutzt die Init-Stuktur?
Weil jetz wird von deinen Pins kein Mode gesetzt. Damit bleiben das
stink normale IO Pins.
Selber machen ist ja ein super Lerneffekt, aber ich würde erst einmal
mit "vorgefertigten" Code probieren ob die Randbedingungen passen.
Adafruit liefert Beispiele. STM32Cube kann dir die SPI Schnittstelle
auch konfigurieren (dann wäre das Pin Init in einer separaten Funktion).
Jens R. schrieb:> Und warum machst du dein dazu geschriebens GPIO Init nicht genauso wie> es dir STM vormacht und nutzt die Init-Stuktur?
Bitte klär mich mal auf wie du das meinst. Ich habe weder die SPI.c noch
die GPIO.c angefasst. Das kommt alles aus dem CodeGenerator der CubeIDE.
Ich habe nur in der .ioc Datei die Parametrierung zusammen geklickt
(siehe Screenshot weiter oben).
beo bachta schrieb:> einen Blick in deine SPI.h und GPIO.h
Häng ich mit an, aber da ist (zumindest aus meiner Sicht) nicht viel
drin.
SPI.c/h und gpio.c/h sind komplett aus dem Generator, ohne User Code
oder ähnliches. Ich habe es gerade noch mal per CubeMX generieren
lassen, sieht identisch aus.
Mir macht etwas Sorge, dass der MISO (PB14) immer mit "Alternate
Function PushPull" angegeben wird, dass müsste doch rein theoretisch ein
Input sein?
jens
jens schrieb:> Häng ich mit an, aber da ist (zumindest aus meiner Sicht) nicht viel> drin.
Ich suchte eigentlich die Pin-Definitionen. Die müssten dann
wohl in main.h stehen. Da sollten wir nochmal herumkramen ....
jens schrieb:> Mir macht etwas Sorge, dass der MISO (PB14) immer mit "Alternate> Function PushPull" angegeben wird, dass müsste doch rein theoretisch ein> Input sein?
Das ist bei meinen Projekten auch so, und es funktioniert. Die
Eigenschaft wird offensichtlich durch die Alternate Function
"überschrieben".
jens schrieb:> Mir macht etwas Sorge, dass der MISO (PB14) immer mit "Alternate> Function PushPull" angegeben wird, dass müsste doch rein theoretisch ein> Input sein?
Schick doch mal auch dein IOC File, oder gleich das ganze Projekt,
am besten auf ein Minimalbeispiel reduziert. Leider habe ich keinen
F303 sonst würde ich das selbst austesten.
Irritiert. Die sahen Hand geschrieben aus. Das Initialisieren passiert
in der "MSP" Funktion.
Alternate-Push-Pull klingt schon richtig. Da müsste ich später mal
nachschauen was es noch gibt.
Aber hast du mal versucht, das Ganze per Arduino Umgebung mit den
Adafruit Beispielen zu nutzen? Oder zumindest mal geschaut, wie die da
die SPI konfigurieren.
Also ich hab das Projekt jetzt mal eingedampft, sind aber immer noch
15MB.
Verhalten nach wie vor (getestet mit dem Projekt was ich hier angehangen
habe):
Trenne ich die Verbindung zwischen MAX und STM32, gibt der MAX Daten
aus. Klemme ich die Sache an, kommt nichts mehr an (Dauer LOW mit sehr
schmalen Peaks im Takt der Clock)
Zip im Anhang, eventuell seht ihr noch was, was ich übersehe.
jens
jens schrieb:> Also ich hab das Projekt jetzt mal eingedampft, sind aber immer noch> 15MB.
Hätte gedacht du kommst drauf mal vorher ein "Clean Project"
auszulösen. Dann schrumpft das Projekt auf ca. 6.5 MB
(unkomprimiert).
jens schrieb:> eventuell seht ihr noch was, was ich übersehe
Kann es sein dass du <CS_MAX31855_Pin> vom F303 zum MAX31855
verdrahtet hast aber du in deiner Test-Loop <SPI2_CS_Pin>
zum Selektieren deines MAX31855 verwendest? Siehe
Macht ja eigentlich keinen Sinn einen extra SPI_CS zu konfigurieren.
Es macht allerdings Sinn hier in der Problembeschreibung zu
dokumentieren was du wirklich verschaltet hast, was du bisher
nicht getan hast.
beo bachta schrieb:> Macht ja eigentlich keinen Sinn einen extra SPI_CS zu konfigurieren.
Sehr aufmerksam, aber:
jens schrieb:> Der CS_MAX31855 Pin ist nicht der, den ich> verwende. Es ist auf der Platine noch ein MAX31855 vorgesehen, aber> aktuell nicht verbaut. Der CS um den es hier geht ist SPI2_CS!beo bachta schrieb:> Es macht allerdings Sinn hier in der Problembeschreibung zu> dokumentieren was du wirklich verschaltet hast
SPI2_MISO hängt an DO des MAX
SPI2_SCK hängt an SCK des MAX
SPI2_CS hängt an CS des MAX
VCC hängt an 5V
GND ist verbunden mit GND des STM32
Alles ist direkt angelötet, quasi Punkt zu Punkt Verbindungen.
Alle OsziBilder sind auf der Platine des MAX gemessen. Die Clock kommt
durch, der CS kommt durch und bei offener Leitung gibt der MAX auch sein
Signal aus.
Nur wenn ich ihn anklemme, dann ist Funkstille (wie auf den Oszi Bildern
zu sehen).
Deine Geduld ist bemerkenswert :).
jens
jens schrieb:> Alles ist direkt angelötet, quasi Punkt zu Punkt Verbindungen.
Ist das Board eine eigene Kreation oder handelt es sich
dabei um ein Nucleo Board?
beo bachta schrieb:> Ist das Board eine eigene Kreation oder handelt es sich> dabei um ein Nucleo Board?
Weder noch, es ist eine "Black Pill" vom Chinamann. Allerdings habe ich
da schon mal den FAKE STM32 runter geworfen und einen originalen von
Mouser drauf gepackt (war noch vor der Chip Krise). Ich habe den
Kollegen auch noch mal nachgelötet, die Beinchen mit dem Mikroskop
kontrolliert und mit dem Multimeter auf Kurzschlüsse (Nachbarpins, GND,
VCC) oder andere Anomalien untersucht. Nichts. Absolut nichts. Ich habe
auch die Pin Bezeichnung überprüft, ob der PB14 laut Bestückungsdruck
auch an PB14 am STM geht --> passt auch.
Dann schlage ich vor du nutzt mal testweise den "originalen"
CS_MAX31855 Pin und disablest im CubeMX den SPI2_CS (PB12).
CubeMX zeigt eine Warnung dass da etwas nicht verträglich
sein könnte, die Details müsste man im Manual nachschauen
wozu ich keine Geduld habe.
beo bachta schrieb:> Dann schlage ich vor du nutzt mal testweise den "originalen"> CS_MAX31855 Pin und disablest im CubeMX den SPI2_CS (PB12).
Habe ich gemacht, kein Erfolg :(.
beo bachta schrieb:> CubeMX zeigt eine Warnung dass da etwas nicht verträglich> sein könnte,
Ich habe den CS Pin auf Hardware gesetzt, dann wählt er PB12 als NSS und
dann verschwindet die Meldung. Aber das Ergebnis bleibt gleich. Der CS
funktioniert sauber, die Clock taktet korrekt der MAX antwortet bei
offener Leitung. Sobald ich MISO verbinde ist es wieder vorbei mit den
Daten.
Es kann doch nicht sein, dass eine simple SPI Kommunikation so derartige
Phänomene verursacht. In einem anderen Projekt habe ich den F303 auch
laufen und lese Daten von einem LTC Baustein mit über 2 Mbit/s. Ohne
Probleme. Die Config sieht genauso aus, ich seh da echt keinen
Unterschied.
Hat noch jemand eine Idee?
jens
Versuche mal noch deinen MISO Pin als normalen Input zu konfigurieren.
Klar wirt man dann keine Daten lesen können, aber es geht erst einmal
nur um das Verhalten, welches du ja mit offener Datenleitung auch
siehst.
Das was du so beschreibst klingt eben sehr kurios.
Hast du schon einmal per Software SPI probiert was passiert?
Jens R. schrieb:> Software SPI
+1
Ich würde jetzt auch mal einfach per SW mit den Pins wackeln. Und mit
dem Oszi schauen, was passiert. So ein SPI ist ja nun keine
Raketentechnik...
jens schrieb:> Habe ich gemacht
Nein hast du nicht gemacht. Ich sprach davon den CS Pin zu
disablen und dafür den anderen CS (nämlich CS_MAX31855)
als alternativen Soft-CS zu verwenden. Dazu musst du nur
einen Draht neu verbinden bzw. umverbinden. Das hätte den Sinn
den Bereich der Schaltmatrix um die Alternative Function
zu "entlasten". Ich weiss, das ist schwarze Magie ....
aber das ist was anderes als das was du an Änderung gemacht
hast.
Auch die SPI-Version "Receive-Only-Master" in CubeMX ein-
zustellen wäre noch einen Versuch (zu obiger Änderung hinzu)
wert.
Wenn die Pin-Wacklerei das die anderen Beitragenden vor-
geschlagen haben nicht hilft dann ist wohl der Chip kaputt
und verdient es mal durch einen neuen ersetzt zu werden.
Oder solltest gerade du einen solch schweren Fehler im
Design von STM gefunden haben?
Jens R. schrieb:> Versuche mal noch deinen MISO Pin als normalen Input zu konfigurieren.
Anbei zwei Bilder. Beides mal PB14. Einmal als Input, einmal als Output.
Geht beides. Gemessen jeweils an dem Kabel, wo normalerweise der MAX
dran hängt. Den habe ich dafür abgelötet.
Einen Layout/Lötfehler schließe ich damit aus.
Jens R. schrieb:> Hast du schon einmal per Software SPI probiert was passiert?
Dafür bin ich wohl noch nicht reif genug, deshalb wollte ich es ja in HW
machen.
beo bachta schrieb:> Ich sprach davon den CS Pin zu> disablen und dafür den anderen CS (nämlich CS_MAX31855)
Ich habe beides gemacht. Einmal NSS auf HW gestellt (CS Signal kommt
sauber) und einmal den CS_MAX31855 ans CS verwendet und den SPI2_CS auf
Reset-State gesetzt. Auch hier kommt das CS sauber.
CS schließe ich als Fehler ebenfalls aus.
beo bachta schrieb:> wohl der Chip kaputt> und verdient
Aber er funktioniert, sowohl Input als auch Output. USB, USART1 alles
IO. Sollte der Chip wirklich partiell kaputt ein?
beo bachta schrieb:> Oder solltest gerade du einen solch schweren Fehler im> Design von STM gefunden haben?
Dann könnten sie die Jahreskosten des Foren-Hostings hier übernehmen, so
als Ausgleich für eure und meine Nerven :).
jens
Noch ein Testvorschlag:
- SPI2 komplett disablen
- PB14 auf Input konfigurieren
- PB15 auf Output konfigurieren
- PB14 und PB15 verbinden
- PB15 wackeln lassen und auf PB14 schauen ob er mitwackelt
(programmtechnisch und messtechnisch überprüfen)
Wenn PB14 mitwackelt dann bin ich am Verzweifeln.
Wenn PB14 nicht mitwackelt dann ist es ein Chip- oder
Designfehler.
Könnte es sein das du durch deine Unerfahrenheit beim
Zusammenlöten den PB14 mal versehentlich mit einer festen
Spannung beaufschlagt hast?
beo bachta schrieb:> Wenn PB14 mitwackelt dann bin ich am Verzweifeln.
Dann dürfen wir jetzt gemeinsam verzweifeln.
Oszi hängt am Kabel zwischen den beiden Pins. MOSI ist Output, MISO ist
Input.
Code:
buffer_max[0] wechselt fleißig zwischen 0 und 1 in der Live View.
Ich hab keine Lust mehr
beo bachta schrieb:> Könnte es sein das du durch deine Unerfahrenheit beim> Zusammenlöten den PB14 mal versehentlich mit einer festen> Spannung beaufschlagt hast?
Nicht das ich wüsste, scheint ja auch alles zu funktionieren.
jens
Problem gelöst, es liegt an den Adafruit Platinen!
Ich habe mehrere durchprobiert, immer das gleiche Phänomen. Dann habe
ich den Max31855 runtergelötet und "direkt" angeklemmt (mit einen
Standard SO8 Breakout Board) und siehe da...die Daten kommen im STM an.
Jetzt ärger ich mich, dass ich das nicht eher getan habe.
Vielen Dank an alle die mir geholfen haben und sich mit mir das Problem
um die Ohren geschlagen haben :).
jens
Thread beobachten
Seitenaufteilung abschalten