STM32F7 Disco und das Display-->hard fault error

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.

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.

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. 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.

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

1

/**

2

  * LCD Frame buffer start address : starts at beginning of SDRAM

3

  */

4

#define LCD_FRAME_BUFFER          SDRAM_DEVICE_ADDR

SDRAM_DEVICE_ADDR steht (glaube ich) in stm32746g_discovery_sdram.h

1

#define SDRAM_DEVICE_ADDR  ((uint32_t)0xC0000000)

1

  /* Initialize the LCD */

2

  lcd_status = BSP_LCD_Init(); 

3

  ASSERT(lcd_status != LCD_OK);

4

5

  /* Initialize the LCD Layers */

6

  BSP_LCD_LayerDefaultInit(LTDC_ACTIVE_LAYER, LCD_FRAME_BUFFER);

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

1

#define LCD_FRAME_BUFFER1          SDRAM_DEVICE_ADDR

2

#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

1

uint32_t framebuffer1[480][272];

2

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:

1

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

2

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.

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...

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.

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.

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

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?

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.

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.

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"