Hi,
ich scheitere gerade daran, mit einem Nucleo STM23F446-Board einen
S/PDIF Datenstrom zu empfangen.
Meine Vorgehensweise:
- In CubeMX habe ich mir den STM auf 180 MHz Systemclock konfiguriert
- PB7 ist als GPIO_INPUT konfiguriert
- wenn ich mit dem so erzeugten Code im main-Loop eine Funktion
HAL_GPIO_ReadPin(GPIOB,0x80) aufrufe, so liefert die abwechselnd
GPIO_PIN_SET und GPIO_PIN_CLEARED zurück, das S/PDIF-Signal liegt also
grundsätzlich an und die HIGH/LOW werden erkannt
- im nächsten Schritt ändere ich PB7 in CubeMX auf SPDIFRX_IN und
verwende folgende Initialisierung (generiert von CubeMX):
- wenn ich jetzt in main-Loop
HAL_SPDIFRX_ReceiveDataFlow(&hspdif,spdifData,8,10000) aufrufe, liefert
mir diese Funktion immer nur einen Timeout, es werden also keine
S/PDIF-Daten erkannt
- der Datenstrom ist korrekt, ein Kontrollgerät empfängt diesen
problemlos
- die Verwendung des Callbacks HAL_SPDIFRX_RxCpltCallback() macht keinen
Unterschied, auch dieser wird niemals aufgerufen
- das S/PDIF-Signal habe ich bereits invertiert um einen Logikfehler in
meiner Schaltung auszuschließen, das hilft auch nicht
- wenn ich mit dem Oszi an Pin 59 des STM nachsehe, dann liegt dort das
S/PDIF-Signal an, das passt also ebenfalls
Wo kann das PRoblem hier noch liegen? Hat jemand eine Idee?
Danke!
Das mit dem GPIO war nur ein Test, ob die Hardware überhaupt etwas an
dem Eingang erkennt.
Tatsächlich soll der STM32 das Signal erkennen -> deswegen wird im
zweiten Schritt ja auch die native SPDIF-Hardware verwendet, welche die
gesamte Synchronisation und den Empfang der Daten übernehmen sollte.
Ich mache immer den Fehler, zwar die Callbacks zu installieren. aber den
Interrupt zu vergessen.
Schau doch noch einmal nach, ob alle notwendigen Interrupts auch
aktiviert sind.
PittyJ schrieb:> Ich mache immer den Fehler, zwar die Callbacks zu installieren. aber den> Interrupt zu vergessen.> Schau doch noch einmal nach, ob alle notwendigen Interrupts auch> aktiviert sind
Ja, den hatte ich auch vergessen, aber das ist leider auch nicht die
Ursache, da die Polling-Funktion ja ebenfalls nichts empfängt
OK, ich suche mir eine andere MCU samt anderem Hersteller. Der Support
von ST ist unter aller Sau, mehr als ein müdes Schulterzucken ist dort
nicht zu bekommen. Das lässt für deren Hardware nichts gutes vermuten.
Jobst M. schrieb:> Wenn Du denen genau so umfangreiche Informationen hast zukommen lassen> wie uns, finde ich das eigentlich gar nicht verwunderlich.
Welche Informationen fehlen dir denn noch? Das war eine vollständige
Beschreibung des gesamten Codes, der Rest wurde von CubeMX generiert und
sollte ST bekannt sein.
Aber du kannst mir gerne Verraten, mit welchen magischen
Zusatzinformationen du das Problem auf Anhieb und umassend lösen kannst!
ZanSouth schrieb:> Welche Informationen fehlen dir denn noch?
Du musst nur lesen, dann könnte Dir auffallen, welche Frage Du (von mir)
nicht beachtet hast.
Wenn Du natürlich erwartest, dass Dein Problem nun mit nur einer Antwort
für Dich gelöst wird, vergiss es aber lieber einfach.
Gruß
Jobst
Matthias S. schrieb:> Mir fällt in deinem Codefetzen auf, das nirgends Taktquellen> konfiguriert werden. Mit S/PDIF Empfänger habe ich hier noch nichts> gemacht, aber für I2S sind die Clocks absolut notwendig - und sie müssen> auch korrekt sein.
CLock ist vorhanden, ich habe den S/PDIF ebenfalls auf 180 Mhz
konfiguriert - Überblick im Anhang (auch die Frage, ob das korrekt ist,
habe ich im ST-Forum mehrfach gestellt und sie wurde genau so ofr von
deren "Support" ignoriert).
Jobst M. schrieb:> Du musst nur lesen, dann könnte Dir auffallen, welche Frage Du (von mir)> nicht beachtet hast.
Ich habe diese Frage von dir beantwortet - wenn du mein ursprüngliches
Posting bis zum Ende gelesen hättest, hättest du die übrigens nicht mal
stellen müssen.
Ach, halt, du willst hier nur rumpöbeln - ja, dann mach' nur weiter,
wenn es dir hilft!
Die AN5073 sagt ziemlich deutlich dass die Anbindung des S/PDIF Signal
an den STM32 nicht trivial ist und die Erkennung im STM32 z.B.
empfindlich
auf Jitter reagiert.
Auch wenn man also am STM32 Pin sieht dass da ein sich änderndes Signal
anliegt heisst das noch lange nicht dass der STM32 damit etwas anfangen
kann (im Bezug auf S/PDIF).
Von daher ist die Frage wie das S/PDIF Signal an den STM32 angebunden
ist durchaus berechtigt.
Es gibt übrigens auch Discovery Boards mit fertiger S/PDIF Hardware,
das wäre eventuell eine Alternative um Probleme bei der Anbindung
auszuschließen.
Dieter schrieb:> Auch wenn man also am STM32 Pin sieht dass da ein sich änderndes Signal> anliegt heisst das noch lange nicht dass der STM32 damit etwas anfangen> kann (im Bezug auf S/PDIF).>> Von daher ist die Frage wie das S/PDIF Signal an den STM32 angebunden> ist durchaus berechtigt.
Die Quelle liefert ein 3,3V S/PDIF-Signal, oder mit anderen Worten: ich
greife das Quellsignal direkt hinter dem Erzeuger ab und leite es dann
ohne Umwege auf den STM. Es ist absolut keine Konvertierung in optische
Signale oder sonstwas vorhanden.
Wenn der STM tatsächlich mit einem "rohen" S/PDIF-Signal nicht klar
kommt, dann ist die Hardware Mist und ich weiß ehrlich gesagt nicht, wie
der mit einem realen S/PDIF-Signal klarkommen soll (welches IMMER einen
Jitter haben wird, speziell wenn da moch irgendwelche
Signalkonvertierungen vorkommen).
Wenn ich es richtig sehe verwendest Du den HSI als Quelle für den Clock.
Hast Du es schon mal mit dem externen Quarz, also HSE versucht?
Hintergrund ist dass man Kommentare findet die die schlechte Qualität
des HSI Clock bei bestimmten Anwendungen erwähnen. Ob das in diesem
Fall etwas ändert weiss ich nicht, aber einen Versuch ist es eventuell
wert (sollte ja recht schnell machbar sein).
ZanSouth schrieb:> Ich habe diese Frage von dir beantwortet
Nein. Auch immernoch nicht. Zumindest sehe ich hier nirgends einen Plan.
Aber ist jetzt auch egal ...
Sieh selbst zu.
Ciao
Jobst
ZanSouth schrieb:> Welche Informationen fehlen dir denn noch? Das war eine vollständige> Beschreibung des gesamten Codes, der Rest wurde von CubeMX generiert und> sollte ST bekannt sein.
Und natürlich kommst Du nicht auf die Idee, Deine IOC-Datei zu
veröffentlichen oder auch nur ansatzweise zu erwähnen, welche Version
von STM32CubeMX Du verwendest.
Aber das ist jetzt eh egal. Vielleicht hilft Dir Mutti ja dabei, nachdem
sie Dir die Schuhe zugebunden hat.
Update für alle, die nicht nur dumm rumpampen wollen sondern an einer
ernsthaften Lösung interessiert sind/ein ähnliches Problem haben:
Ich habe mittlerweile auf den MIMX RT1010 von NXP gewechselt und dort
funktioniert der S/PDIF-Empfang auf Anhieb.
Es ist also kein Problem mit meiner Verdrahtung/der Anbindung an das
Evaluationboard, die sind hier beim STM und beim RT1010 nämlich
identisch gelöst - direkte 3,3-V-Leitungen von der Quelle auf den
Eingang der jeweiligen MCU.
Fazit: es dürfte ein Problem in der STM-Hardware oder in der
CubeMX-Software des STM sein, an dem der STM-Support aber auch in
keinster Weise interessiert ist.
Mit der MCUexpresso-IDE lässt sich eine funktionierende Lösung mehr oder
weniger auf Anhieb erstellen. Und der Support von NXP ist auch
wesentlich reaktionsfreudiger und kompetenter.
ZanSouth schrieb:> - das S/PDIF-Signal habe ich bereits invertiert um einen Logikfehler in> meiner Schaltung auszuschließen, das hilft auch nicht
Das kann nichts bringen, weil man das S/PDIF grundsätzlich invertieren
darf und es dann trotzdem noch funktioniert.
ZanSouth schrieb:> Fazit: es dürfte ein Problem in der STM-Hardware oder in der> CubeMX-Software des STM sein
Abtastrateninkompatibilität?
Oder kommt S/PDIF mit 24 und er kann nur 20?
Audiomann schrieb:> Abtastrateninkompatibilität?
Naja, wenn man dem Clockschema da oben trauen darf, hat der TE das alles
mit dem HSI getaktet. Das muss also nicht funktionieren. Da sollte man
schon echten Quarzbetrieb vorsehen.
Matthias S. schrieb:> Das muss also nicht funktionieren. Da sollte man> schon echten Quarzbetrieb vorsehen.
Möglich. Das ist dann aber etwas, was der Support von ST wissen müsste.
Aber von da kam ja gar nix brauchbares.
ZanSouth schrieb:>> Möglich. Das ist dann aber etwas, was der Support von ST wissen müsste.> Aber von da kam ja gar nix brauchbares.
Es wäre aber auch relativ einfach gewesen von HSI auf HSE zu wechseln
und zu schauen ob das was ändert. Dazu braucht man nicht den Support
von ST.
Ich hatte inzwischen die Gelegenheit SPDIF-Rx in der selben Konfiguration auszuprobieren (STM32F446 Nucleo-64 Board, SPDIF Quelle mit 3.3 Volt Pegel direkt an Pin PB7). Das funktioniert hier problemlos, sowohl mit HSE als auch HSI als Taktquelle (getestet mit Samplerate 48 kHz und 44.1 kHz).
