Bei den STM32H7 (konkret: STM32H755BIT6) lässt sich der FMC für externe SDRAMs nutzen. In den Konfigurationen für 16 Bit und 32 Bit breite SDRAMs werden durch STM32CubeMX auch die Signale FMC_NBLx (zu verbinden mit DQMx des SDRAMs) korrekt generiert. In der 8-Bit-Variante fehlt jedoch ein entsprechendes Signal. Übliche 8-Bit-SDRAMs (z.B. Alliance AS4C32M8SA) wollen jedoch auch ein DQM-Signal sehen. Hat STM hier Mist gebaut oder kann man in diesem Fall DQM mit CS# bzw. FMC_SDNE0 verbinden? Laut Datenblättern soll für eine korrekte Initialisierung DQM zunächst auf High liegen und erst später auf Low gepulst werden. Darf man etwa DQM auf einen GPIO-Ausgang legen und nach der Initialisierung dauerhaft auf Low legen, ohne dass es bei der RW-Richtungsumschaltung zu Buskollisionen kommen kann?
:
Bearbeitet durch User
Dieses Problem wurde auch schon hier thematisiert, aber leider ohne erprobte Lösung: https://electronics.stackexchange.com/questions/422204/connect-micron-sdram-to-stm32h7-fmc-what-should-i-do-with-the-dqm-pin Setzt hier wirklich niemand (wegen Pinmangels) ein 8-Bit-SDRAM ein?
Andreas S. schrieb: > Setzt hier wirklich niemand (wegen Pinmangels) ein 8-Bit-SDRAM ein? Klingt zu exotisch, fast so exotisch wie 4 Bit SDRAM, den es am ATXmega mal gab.
sind das die Hyper RAM die auf den Discos drauf sind? Da müsste es ja eine funktionierende Konfig geben.
J. S. schrieb: > sind das die Hyper RAM die auf den Discos drauf sind? Da müsste es ja > eine funktionierende Konfig geben. Nein, die Hyperbus RAMs gibt es nur für diejenigen STM32H7-Derivate mit einem OCTOSPI-Periherieblock. "Unser" STM32H757 hat keinen solchen, könnte aber ggf. PSRAMS mit gemultiplextem Bus ansteuern, und zwar über den FMC und nicht OCTSPI. Bei beiden dieser Busse sind Adressen und Daten gemultiplext. Das macht die Sache nicht unbedingt schneller. Eigentlich will ich lieber ein 16-Bit-SDRAM verwenden, bin mir aber noch nicht hundertprozentig sicher, ob ich alle benötigten Pins freigeschaufelt bekomme. Derzeit habe ich noch ein paar Konflikte. Mit einem konventionellen 8-Bit-SDRAM gäbe es noch eine gewisse Rückfalllösung. Wir haben beschlossen, eine offizielle Anfrage bei STM zu stellen, da mein Kunde dort einen direkten technischen Ansprechpartner hat. Mal schauen, welche Information es dort gibt. Vielleicht ist es ja wirklich nur ein Fehler im STM32CubeMX, und man kann einfach PE0 auf AF12 konfigurieren.
:
Bearbeitet durch User
Andreas S. schrieb: > Eigentlich will ich lieber ein 16-Bit-SDRAM verwenden, Tu das. Man sollte so weit wie möglich Standardkram benutzen, wenn man sich nicht sinnlos Stress machen will. > bin mir aber noch > nicht hundertprozentig sicher, ob ich alle benötigten Pins > freigeschaufelt bekomme. Wofür brauchst du die Pins? Für schnelle Sachen oder langsame? Letzeres machen Portexpander. Oder Multiplexing (für Tasten, LEDs, etc.)
Angehängte Dateien:
-
PE0_AF12.png
64 KB
Andreas S. schrieb: > Vielleicht ist es ja wirklich > nur ein Fehler im STM32CubeMX, und man kann einfach PE0 auf AF12 > konfigurieren. Öh, also laut Datenblatt von St geht das so. Siehe Bild.
Falk B. schrieb: > Andreas S. schrieb: >> Eigentlich will ich lieber ein 16-Bit-SDRAM verwenden, > > Tu das. Man sollte so weit wie möglich Standardkram benutzen, wenn man > sich nicht sinnlos Stress machen will. Wie schon gesagt: voraussichtlich Pinknappheit. > Wofür brauchst du die Pins? Für schnelle Sachen oder langsame? Letzeres > machen Portexpander. Oder Multiplexing (für Tasten, LEDs, etc.) Volldampf per Ethernet, vier SPIs, drei UARTs, zwei I2C, zwei CAN und beiden USB. Und dazu noch ein eMMC. Alleine diese ganzen dedizierten Blöcke auf die Pins zu verteilen ist schon nicht ohne Kompromisse zu machen. Aber das ist ja auch der Grund, aus dem wir solch einen dicken Microcontroller wie den STM32H757 einsetzen.
Max H. schrieb: > Öh, also laut Datenblatt von St geht das so. Siehe Bild. Genau das meinte ich ja damit, AF12 für PE0 zu konfigurieren. Ich finde nirgendwo etwas gegenteiliges in der Dokumentation von STM. Dort wird ja eine Datenbusbreite von 8 Bit für SDRAM explizit aufgeführt. In STM32CubeMX steckt heutzutage aber auch ziemlich viel Insiderwissen über Fehler in den Bausteinen selbst. Wenn man sich den generierten Code anschaut, findet sich so mancher Workaround, vermutlich auch für nicht öffentlich dokumentierte Fehler. Vielleicht ist ja STM ein Fehler bei der NBL0-Erzeugung im 8-Bit-Modus bekannt. Statt das ins Errata Sheet zu schreiben, wird NBL0 einfach nicht aktiviert. Problem gelöst. Mal schauen, wie die offizielle Stellungnahme von STM aussieht.
Andreas S. schrieb: > Volldampf per Ethernet, vier SPIs, drei UARTs, zwei I2C, zwei CAN und > beiden USB. Und dazu noch ein eMMC. Klingt ja nach der ultimativen Killerapplikation! Viel Erfolg!
Ja, die H7 sind schon eine harte Nummer, auch für STM selber. Es gibt noch keinen fehlerfreien generierten oder Beispielcode für Ethernet: https://community.st.com/s/question/0D53W000022LEvMSAW/lwip-v650-stmh32h735disco-httpsgithubcomstm32hotspotstm32h7lwipexamples-rxpoolsection-former-rxarraysection-seems-not-to-be-guarded-by-the-mpu-against-cache-coherency-issues-is-this-the-right-way
:
Bearbeitet durch User
Falk B. schrieb: > Klingt ja nach der ultimativen Killerapplikation! Viel Erfolg! Nö, es geht nur um einen Demonstrator, um die Machbarkeit verschiedener Dinge zu zeigen. Darauf basierend werden dann die Leistungsmerkmale für das eigentliche Serienprodukt bestimmt und die Hardware entsprechend zusammengestrichen. Das ist in diesem Fall deutlich besser als der umgekehrte Weg, nämlich ein Minimalprodukt zu definieren und es anschließend immer wieder aufzubohren und dabei dann einen Haufen fauler Kompromisse eingehen zu müssen. Es geht in diesem Projekt für meinen Kunden darum, eine Plattform für eine sehr langlebige Produktfamilie zu schaffen.
J. S. schrieb: > Ja, die H7 sind schon eine harte Nummer, auch für STM selber. > Es gibt noch keinen fehlerfreien generierten oder Beispielcode für > Ethernet: Diese Diskussion bezieht sich wohl primär auf den lwIP-Stack, der eben bei STM aus der Tüte fällt, bzw. den HAL-Treiber für Ethernet. Hier eine weitere Problemschilderung: https://stmh7.com/001-the-ethernet-hal/ Jedoch gibt es auch den FreeRTOS-eigenen TCP/IP-Stack ("FreeRTOS plus TCP"), zu dem es wiederum auch zwiespältige Diskussionen bezüglich der Eignung bzw. Portierung auf den STM32H7 gibt, z.B.: https://forums.freertos.org/t/freertos-tcp-stm32h7-support/12802 Die FreeRTOS-Version (10.3.1), die bei STM32CubMX herausfällt, ist dummerweise auch rund drei Jahre gegenüber der aktuellen Version veraltet. FreeRTOS Plus ist darin nicht enthalten. Da es großenteils in einer separaten Verzeichnisstruktur liegt, kann man durchaus auch unterschiedliche Versionen des Kernel und der Erweiterungen nutzen. Mittlerweile ist AWS ja auch dazu übergegangen, nicht mehr alles mit einer festen Versionskennung zu versehen, sondern die verschiedenen Anteile separat zu versionieren. Zusammengefasst wird das dann durch Pakete wie z.B. FreeRTOS 202212.01. Natürlich möchten wir die aktuellste Version des Netzwerkteils usw. nutzen und nicht die korrespondierende, uralte Version. Allerdings kann es ja durchaus subtile Abhängigkeit geben, so dass man auch der Kernel nachziehen muss und sich somit der Codegenerierung durch STM32CubeMX entzieht. Andererseits fand ich es bisher auch oft eher lästig, die FreeRTOS-Konfiguration immer mit STM32CubeMX durchführen zu müssen; insbesondere die Default-Task lässt sich ja nicht entfernen. Erst für neue Prozessoren wie STM32H5 bietet STM neuere FreeRTOS-Bibliotheken an. Der H7 gilt da schon als "legacy". :-/
Andreas S. schrieb: > Diese Diskussion bezieht sich wohl primär auf den lwIP-Stack, der eben > bei STM aus der Tüte fällt, bzw. den HAL-Treiber für Ethernet die Probleme gehen da tiefer, sind auch ohne RTOS vorhanden, kommen rein von DMA und Cache.
J. S. schrieb: > Andreas S. schrieb: >> Diese Diskussion bezieht sich wohl primär auf den lwIP-Stack, der eben >> bei STM aus der Tüte fällt, bzw. den HAL-Treiber für Ethernet > > die Probleme gehen da tiefer, sind auch ohne RTOS vorhanden, kommen rein > von DMA und Cache. Klar, deswegen schrieb ich ja auch: "zwiespältige Diskussionen bezüglich der Eignung bzw. Portierung auf den STM32H7". Die dort geschilderten Probleme beziehen sich ja auch auf den reinen Ethernet-Treiber. Gibt es überhaupt irgendwelche STM32H7-basierten Produkte auf dem Markt, bei denen der Ethernet-Port zuverlässig funktioniert? Wer die beschriebenen Probleme gelöst hat, hat damit ggf. einen ordentlichen Wettbewerbsvorteil.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.