STM32F7 Disco und das Display-->hard fault error

[J. T. (chaoskind)]

MoinMoin,

ich versuche mich nun schon seit 2 Tagen durch die ganzen HAL-Treiber 
und was noch alles dazugehört durchzuwühlen, um das Display auf dem 
STM32F7-Discoboard zu benutzen. Inziwschen hab ich es soweit, das ich 
ein Projekt compilieren kann, und das Display mir den Status "ready" 
zurückgibt. (ich programmiere mit der IAR workbench 30Tage trial 
lizenz).

Ich erstelle Buffer für den Vorder- und Hintergrundlayer, Variablen für 
x und y Position (um Zeile 110 in der main). Dann kommt der ganze 
Initialisierungskrams von CUBE. Um Zeile 150 kommt dann die 
Initialisierung vom Display. Und hier gehen die Probleme los, bzw 
eigentlich schon beimm Framebuffer.
Wenn ich den Framebuffer so groß wie das Display mache(480*272) dann 
kommt beim Debuggen ein "CSTACK-ERROR" der Stack liegt irgendwo bei 
0x18000000 statt bei 0x20000000 (Die Adressen sind nur ganz grob aus dem 
Kopf).
Daraufhin hab ich den Buffer bis auf 10*10 verkleinert.
In diesem Fall wirft er aber schon während der BSP_LCD_Init() einen
"        PUBWEAK HardFault_Handler
        SECTION .text:CODE:NOROOT:REORDER(1)
HardFault_Handler
        B HardFault_Handler"

Wenn ich jedoch den FrameBuffer auskommentiere (und die Übergabe in der 
LCD_Layerinit()), dann kann ich bis zur Pixelsetz-Funktion durchsteppen. 
Die läuft dann auch, um aber wenn y auf Zeile 7 ist, in den 
HardFaultHandler....

Also irgendwas läuft definitiv falsch. Ich vermute, das liegt daran, das 
er den Buffer in den Flash reintun will. Aber einer von den Beiden ist 
ja schon etwas über 4MB groß (480*272*32bit(ARGB)).
Muss ich den Buffer explizit in den RAM setzen? Wenn ja, wie mach ich 
das? Und warum kümmert sich da der Compiler nicht drum, wenn im RAM 
reichlich Platz ist, im Flash aber nicht?

Mit verwirrten Grüßen, und Hoffnung auf Hilfe
Chaos

Im Anhang die main und die meiner Meinung nach wichtigen Header, falls 
noch was fehlt, gerne nachfragen =)

[hp-freund (Gast)]

Dann hast Du nur noch 28 Tage Zeit :-)

Falls Du von der Spiel-IDE weg kannst, hier das Grafikbeispiel für 
eclipse:

Beitrag "Re: STM32F7 Discovery Board"

In den Beiträgen dort findest Du auch Hinweise für Keil.

[J. T. (chaoskind)]

Den Post hatte ich schon im Thread gelesen. Aber das sah mir alles so 
nach Linux aus. Bekommt man das auch unter win8.1 zum laufen? Denn vor 
dem, was nach den 28Tagen kommt, hab ich jetzt schon Angst. Ich sehs 
schon kommen. Gerade endlich verstanden wie das alles läuft, zack Zeit 
alle. Dann versucht mans woanders mit und alles is mau geht wieder ganz 
anders.

Mit EM:Blocks mein ich mal ganz gute Erfahrungen gemacht zu haben. Evtl 
wars aber Code:Blocks und ich hab aufm Rechner C geübt und nicht auf nem 
Controller.....

[hp-freund (Gast)]

Also wenn man es genau nimmt ist es ein Makefile Projekt und benötigt 
eigentlich keine IDE.
Das ist der pure Luxus ;-)

Im Debug bzw. Release Ordner befinden sich die Makefiles, weiss jetzt 
aber nicht mehr ob ich die aus Platzgründen aus der zip entfernt habe.

eclipse unter Win sollte eigentlich genauso funktionieren.
Evtl. müssen einige Pfadnamen angepasst werden.

[hp-freund (Gast)]

Beitrag "STM32-Toolchain mit Eclipse CDT 4.3, GnuArmEclipse, OpenOCD 0.8.0, Gnu Arm GCC 4.8, STM32CubeMX"

zeigt die Einrichtung von eclipse und Freunden für Win.

[J. T. (chaoskind)]

Werd ich mir mal anschauen, danke dir soweit erstmal!

Zielführende Antworten zum Hardfault und dem FrameBuffer sind übrigens 
immer noch gerne erwünscht ;-)

[Christoph S. (mixer)]

Hallo,

schau dir mal den Stack nach dem hart fault an. Dort liegen sowohl ein 
paar Arbeitsregister als auch der Inhalt des Program Counters bei dem 
der hart fault ausgeloest wurde. Somit kommst du schon mal an die 
Codestelle wo was fehlerhaftes passiert.

Viele Gruesse
cs

[m.n. (Gast)]

J. T. schrieb:
> Wenn ich den Framebuffer so groß wie das Display mache(480*272) dann
> kommt beim Debuggen ein "CSTACK-ERROR" der Stack liegt irgendwo bei
> 0x18000000 statt bei 0x20000000 (Die Adressen sind nur ganz grob aus dem
> Kopf).

Ich würde die Einstellungen unter Options/Linker kontrollieren. Die 
Datei *.icf zeigt die aktuellen Einstellungen.
Solange dort etwas im Argen liegt, wird ein fehlerfreies Programm 
erzeugt, was aber nicht laufen kann.

Es wird auch ein Demoprogramm mit Display für IAR geben; vielleicht 
findest Du dort die richtigen Einstellungen, ohne selber experimentieren 
(denken) zu müssen.

[KlausR (Gast)]

Also, m.E. muss der FrameBuffer im SDRAM liegen. Du benötigst für einen
480x272x32 bit ARGB Buffer 512 kB RAM. Soviel hat der STM32F746 intern 
gar nicht.

Ich habe verwende auch die BSP_LCD Funktionen. Im Beispiel 
DiscoF7_BSP.zip wird der Framebuffer direkt auf den Anfang des SDRAMs 
gelegt, d.h. der Compiler verwaltet das SDRAM gar nicht. Das sieht dann 
so aus:
In main.h

/**
  * LCD Frame buffer start address : starts at beginning of SDRAM
  */
#define LCD_FRAME_BUFFER          SDRAM_DEVICE_ADDR

SDRAM_DEVICE_ADDR steht (glaube ich) in stm32746g_discovery_sdram.h

#define SDRAM_DEVICE_ADDR  ((uint32_t)0xC0000000)

  /* Initialize the LCD */
  lcd_status = BSP_LCD_Init(); 
  ASSERT(lcd_status != LCD_OK);

  /* Initialize the LCD Layers */
  BSP_LCD_LayerDefaultInit(LTDC_ACTIVE_LAYER, LCD_FRAME_BUFFER);

Willst du zwei Frame Buffer haben, dann musst du halt sowas defnieren:

#define LCD_FRAME_BUFFER1          SDRAM_DEVICE_ADDR
#define LCD_FRAME_BUFFER2          ((uint32_t)(SDRAM_DEVICE_ADDR + 480*272*4)) // ARGB 4 bytes per pixel

Wichtig ist halt, dass der IAR entweder das sdram gar nicht verwaltet 
(dann vorgehen siehe oben) oder wenn er es verwaltet, dann musst du ihm 
sagen, dass deine Variablen

uint32_t framebuffer1[480][272];
uint32_t framebuffer2[480][272];

im SDRAM liegen. Wie das beim IAR geht, weiß ich leider nicht! Beim
gcc geht das mittels geeigneter Linker scripts und _attribute_ 
((section ("SDRAM"))), wobei im Linkerscript dann eine section SDRAM 
definiert sein muss.

Sieht dann ungefähr so aus:

uint32_t framebuffer1[480][272] __attribute__ ((section ("SDRAM"))) ;
uint32_t framebuffer2[480][272] __attribute__ ((section ("SDRAM"))) ;

Ach ja: Ich habe das o.g. Beispiel DiscoF7_BSP.zip hier, dass der 
Release Zweig  als reines Makefile Projekt kompiliert, also ohne die 
fest eingebundenen absoluten Pfade (aus Eclipse). Falls das jemand 
braucht?
Kompiliert ohne Änderung auf Windows und Linux Rechnern! Als Umgebung 
benötigt man nur den GCC ARM Embedded aus dem launchpad und GNU Make.

[KlausR (Gast)]

Ach ja: Zu deinem IAR Problem: http://supp.iar.com/Support/?note=27498

Was machst du eigentlich, wenn die 30 Tage rum sind? Kaufst du dann den 
Compiler? Wenn nicht, ist jedes weitere verwenden des IARs vertane 
Zeit...

[KlausR (Gast)]

Noch was: Eine m.E. gute Erklärung der GNU Linker Scripts findet man 
hier http://www.atmel.com/Images/doc32158.pdf auch wenn das eigentlich 
für AVR32 gedacht ist.

[m.n. (Gast)]

KlausR schrieb:
> Was machst du eigentlich, wenn die 30 Tage rum sind? Kaufst du dann den
> Compiler? Wenn nicht, ist jedes weitere verwenden des IARs vertane
> Zeit...

Quatsch! Zum Entwickeln ist er sehr gut, danach kann man mit EM:Blocks 
weitermachen.

[KlausR (Gast)]

Ach, macht also Sinn, mitten in einer Entwicklung die IDE zu wechseln? 
Super Idee!
Nebenbei: Dass der IAR gut ist, bezweifelt ja niemand...

[m.n. (Gast)]

KlausR schrieb:
> Ach, macht also Sinn, mitten in einer Entwicklung die IDE zu wechseln?

Ich mache weder Unterschied noch Sinn, aber ich mache flexibel.
Ich verwende z.B. die Kickstarter IDE, um Programmteile mit 'live watch' 
anzutesten. Den Quellcode kann man dann 1:1 in EM:Blocks verwenden und 
umgeht damit die Größenbeschränkung.
Was soll sein?

[KlausR (Gast)]

Ok. Die IDE läuft code-size limitiert weiter. Dann kann das dann doch 
Sinn machen. Hatte in Erinnerung (wohl falsch), dass die IAR IDE das 
arbeiten nach den 30-Demo-Tagen komplett einstellt.

[Jörg (Gast)]

m.n. schrieb:
> Den Quellcode kann man dann 1:1 in EM:Blocks verwenden und
> umgeht damit die Größenbeschränkung.

Hast Du ein Beispielprojekt für EMBlocks mit dem F7?
Wirklich unsterstützen tut ja nichtmal Blitz den.

[Thomas S. (doschi_)]

oder OpenSTM32-Workbench?  www.openstm32.org
(siehe bei Uwe: 
http://mikrocontroller.bplaced.net/wordpress/?page_id=5241)

[m.n. (Gast)]

Jörg schrieb:
> Hast Du ein Beispielprojekt für EMBlocks mit dem F7?
> Wirklich unsterstützen tut ja nichtmal Blitz den.

Das habe ich leider nicht.
Obwohl ich das F7-Discovery-Board mit Rabatt hätte beziehen können, habe 
ich es mir nicht besorgt, da es zu verbaut ist und für mich keinen 
praktischen Nutzen bietet. An anderer Stelle hatte ich das ein wenig 
begründet: Beitrag "Re: MMBasic auf dem STM32F746 Discovery"

[J. T. (chaoskind)]

Danke euch, vor allem Klaus, für die zahlreichen Antworten.

Also in dem Display-Demo Bsp hab ichs auf die Schnelle auch nicht 
gefunden, mein aber, daß da das RTOS mit benutzt wurde.

Ich denke ich werd mir wieder EM:BLOCKS installieren. So toll fand ich 
den IAR jetzt garnicht. Das Syntaxhighlighting kommt mir im Vergleich 
zum Avrsrudio ziemlich schwach vor. Automatische Erweiterung von 
angefangenen Variablen oder structs macht er auch nicht.

Aber ich werd mir im IAR nochmal anschauen, wie ich den Buffer dann ins 
SDRAM bekomm.

MfG  Chaos

[Karl H. (kbuchegg)]

Also ich hab mir bei Aushändigung des neuen Disco Boards auch die STM 
Workbench installiert.
Wo ich das Display Demo herhatte (mitgeliefert?), weiss ich gar nicht 
mehr. Aber es hat auf Anhieb funktioniert und diente als Basis, um es zu 
verändern.

Es hat zwar eine Weile gedauert, bis ich mit Eclipse warm wurde, aber 
jetzt gehts schon einigermassen.

[J. T. (chaoskind)]

Eclipse Han ich mir gestern auch noch nach der Anleitung sie weiter oben 
verlinkt ist, installiert. Bin aber noch nicht dazu gekommen, alles so 
einzurichten, das es läuft.

[Karl H. (kbuchegg)]

J. T. schrieb:
> Eclipse Han ich mir gestern auch noch nach der Anleitung sie weiter oben
> verlinkt ist, installiert. Bin aber noch nicht dazu gekommen, alles so
> einzurichten, das es läuft.

??
Ich hab von OpenSTM die Workbench geholt, installiert und losgelegt. 
Einrichten musste ich da nichts mehr.

[J. T. (chaoskind)]

Bin jetzt ertmal auf der maloche, kann also nicht nachschauen, aber 
nachdem ich dann endlich alles installiert hatte, wurden erstmal über 
100 Errors geworfen. Hat wohl damit zu tun, das die ganzen libs und Co 
noch falsch liegen... ich werd mich heut abend/Nacht nochmal mit 
befassen und mich dann melden.

Bis dahin erstmal nen schönen Sonntag :-)