Hallo zusammen. Ich versuche gerade, auf Basis des STM32F7DISCO Boards ein Basisprojekt zu schaffen, um per Display Daten hübsch darzustellen. Dazu soll STemWin laufen. Ein herunterstrippen der aufgeblähten Demo-Software hat sich als nicht zielführend erwiesen, da sich das Programm zufällig aufhängt. Debuggen (zumindest für mich als Noob) nicht möglich, da in dem Fall keine Verbindung mehr per STLink besteht. Jetzt habe ich das StemWin-Example genommen (STM32Cube_FW_F7_V1.3.0\Projects\STM32746G-Discovery\Applications\STemWi n\STemWin_HelloWorld) und diesem beigebracht, BMPs aus dem QSPI zu laden. Seitdem hängt auch dieses Programm sich sporadisch auf. Ich lasse dazu einen Counter durchlaufen, der nach spätestens einigen Minuten hängt. Nehme ich die Darstellung des Bitmaps aus der Dauerschleife, gibt es keine Probleme. Irgendeine Idee, was hier los sein könnte? Als nächstes werde ich versuchen, die Bilder beim Start ins SDRAM zu laden, um das QSPI-Flash im Dauerbetrieb zu umgehen. Achja, als IDE/Toolchain kommt der System Workbench zum Einsatz
Hallo Tobias, schau mal in diesem Thread nach: Beitrag "STM32F7-Discovery -> eclipse Projekt -> instabil :-(" Ich hatte auch schon Probleme mit einigen Hängern und habe das Problem durch die Kompiliereigenschaften gelöst. Ich persönlich bin von dem Projekt vom hp-freund ausgegangen und habe alle existierenden Module gelöscht und meine eigenen eingesetzt (ein Minesweeper Spiel und ein "Spiel" in dem man Spinnen, die über den Bildschirm laufen, per antippen zertrümmern kann und neue wieder aufleben lassen). Viele Grüße, macload1
Oh, ich habe gerade erst gesehen, dass du in dem Thread schon gepostet hast. Ich benutze Eclipse und OpenOCD als Debugging-Umgebung und es klappt einwandfrei.
Die Compilersettings machen bei mir leider keinen Unterschied. Dachte ich bring das Thema mal neu auf, da ich das Problem bis jetzt nur dem QSPI Flash zuordnen kann. Kenne mich mit der HAL bzw sonstigen Eigenheiten und Bugs des STM32 noch nicht aus. Mit lesen aus dem internen Flash und SDRAM gibt's bis jetzt keine Probleme
Gut, also bis heute habe ich (leider) nur folgende Erkenntnisse bekommen: Ich lade nun alle Bitmaps (ca. 3 MB insgesamt) beim Start vom QSPI Flash ins SDRAM, wenn es Probleme gibt, treten Sie also schon beim Start auf. Die Anwendung bleibt stehen... ...um so mehr Bilder insgesamt im Flash sind (Adressierung?) ...um so größer diese Bilder sind (vermutlich gibts deshalb bei vielen Anwendungen keine Probleme) ...je höher die Taktfrequenz des QSPIs ist. Aktuell kann ich alle Bitmaps komplett (und bei jedem Start!) laden, wenn ich einen Takt von 27 MHz setze. STemWin macht hier zumindest beim direkten lesen aus dem Flash schon nicht mehr mit. Mit dem vorherigen Laden funktionierts für mich. Nur schön ist die "Lösung" nicht ;)
Oder aber man ändert in der stm32746g_discovery_qspi.h folgendes:
1 | |
Läuft! :) bis jetzt.