STM32F7 QSPI Freeze

[Tobias B. (roxxity)]

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

[Mac L. (macload1)]

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

[Mac L. (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.

[Tobias B. (roxxity)]

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

[Tobias B. (roxxity)]

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 ;)

[Tobias B. (roxxity)]

Oder aber man ändert in der stm32746g_discovery_qspi.h folgendes:

s_mem_mapped_cfg.TimeOutActivation = QSPI_TIMEOUT_COUNTER_DISABLE;

Läuft! :) bis jetzt.