STM32F429 Disco Board: SDRAM benutzen

http://en.radzio.dxp.pl/stm32f429idiscovery/sdram.html

Es finden sich schon in CMSIS_Boot Init Routinen für den Memory 
Controller, ob man noch mehr als die braucht weiss ich nicht.


#ifdef DATA_IN_ExtSRAM
/**
  * @brief  Setup the external memory controller.
  *         Called in startup_stm32f4xx.s before jump to main.
  *         This function configures the external SRAM mounted on 
STM324xG_EVAL/STM324x7I boards
  *         This SRAM will be used as program data memory (including 
heap and stack).
  * @param  None
  * @retval None
  */

void SystemInit_ExtMemCtl(void)


Ich weiss nur nicht wo ich diese defines aktiviere, im eigenen Source 
Code?. Wie gesagt... für Anfänger..... der nichts weiter vor sich hat 
als

void main()
{
     InitSystem();

      ......


}

und gern da Code einfügen möchte, um das Gesagte zu machen.

Mein Wissen ist einige Jahre alt aber beim LPC2368 mit GCC
konnte ich sowas verwenden:

uint32_t batram_id _attribute_ ((section(".batram")));

d.h. "batram_id" wurde aufs Segment .batram abgebildet.

oder

// Der Zeichenpuffer das Display hat 40 x 20 Zeichen = 800 Zeichen
uint8_t GD_CharBuf[MAX_LINE][MAX_LPOS+1]  _attribute_ 
((section(".usbram")));
uint8_t GD_OldBuf[MAX_LINE][MAX_LPOS+1]  _attribute_ 
((section(".usbram")));

das eben aufs ".usbram" weil der uC unterschiedliche RAM Bereiche hatte, 
einen gepufferten, einen für USB usw. Alles mit dem GCC gemacht worden.

Lasse S. schrieb:

> Die sections musst du im Linkerscript natürlich angeben

Duuu... wo finde ich das Ding in einem "automatisierten" CooCox Projekt? 
wo man sich die Konfig ja zusammen klickt .... seufz

Ok, habs gefunden, ich meine nicht das Skript aber die Lösung von Uwe 
Becker:


   .HeapMemSection :
    {
        *(.HeapMemSection)
    } > sdram


Leider wenig Ahnug von der seltsamen Sytax aber da müsste sich doch auch 
noch ein weiteres Segment, zb .data reinquetschen lassen, ohne dass die 
kollidieren. Hier ist der Heap jetzt dorthin bugsiert worden.

Rest kompiliert und spielt wie vermutet.....

#define  BUFFER_SIZE  (1024*1024)
uint8_t buffer[BUFFER_SIZE]  attribute__((section(".HeapMemSection")));

/* 18.12.2013 angepasst von UB auf STM32f429i-Disco-Board */


OUTPUT_FORMAT ("elf32-littlearm", "elf32-bigarm", "elf32-littlearm")
/* Internal Memory Map*/
MEMORY
{
  rom (rx)    : ORIGIN = 0x08000000, LENGTH = 0x00200000
  ram (rwx)   : ORIGIN = 0x20000000, LENGTH = 0x00030000
  ram1 (rwx)  : ORIGIN = 0x10000000, LENGTH = 0x00010000
  sdram (rwx) : ORIGIN = 0xD0100000, LENGTH = 0x00400000
}

_eram = 0x20000000 + 0x00020000;
/* Section Definitions */
SECTIONS
{
    .text :
    {
        KEEP(*(.isr_vector .isr_vector.*))
        *(.text .text.* .gnu.linkonce.t.*)
        *(.glue_7t) *(.glue_7)
        *(.rodata .rodata* .gnu.linkonce.r.*)
    } > rom

    .ARM.extab :
    {
        *(.ARM.extab* .gnu.linkonce.armextab.*)
    } > rom

    __exidx_start = .;
    .ARM.exidx :
    {
        *(.ARM.exidx* .gnu.linkonce.armexidx.*)
    } > rom
    __exidx_end = .;

    . = ALIGN(4);
    _etext = .;
    _sidata = .;

    .data : AT (_etext)
    {
        _sdata = .;
        *(.data .data.*)
        . = ALIGN(4);
        _edata = . ;
    } > ram

    /* .bss section which is used for uninitialized data */
    .bss (NOLOAD) :
    {
        _sbss = . ;
        *(.bss .bss.*)
        *(COMMON)
        . = ALIGN(4);
        _ebss = . ;
    } > ram

    /* stack section */
    .co_stack (NOLOAD):
    {
        . = ALIGN(8);
        *(.co_stack .co_stack.*)
    } > ram

    . = ALIGN(4);
    _end = . ;

    .HeapMemSection :
    {
        *(.HeapMemSection)
    } > sdram
}

[/code]

Hallo,

Ich schiebs nochmal hoch. Dass es kompilierte heisst ja noch nichts.

Ist es überhaupt möglich das SDRAM in einer Section zu verwenden? Denn 
diese Zuweisung spielt sich bereits beim Kompilieren ab, bevor das SDRAM 
überhaupt da ist, denn dieses wird erst im Hauptprogramm durch den 
Memory Controller in seiner Geometrie initialisiert und mit einem Takt 
versorgt. Nun haben Compiler aber auch Initsequenzen, wo sie statische 
Variablen aus dem ROM ins Ram kopieren im Startup Code usw.

Jedenfalls ist es bei mir nicht möglich sich den Inhalt des SDRAM im 
Debugger anzeigen zu lassen, da steht nur wirres Zeugs drin. 
Einschrieben von Vars geht aber und sie werden auch korrekt gelesen.

Wie steht es aber nun zb mit der verwendung als Stack? Oder Heap?

Gruss,
Christian

Christian J. schrieb:
> Wie steht es aber nun zb mit der verwendung als Stack? Oder Heap?
Was sollte der Verwendung entgegen stehen?
Jeder PC arbeitet mit dynamischen Speicher.

Du mußt nur sicherstellen, das der Speicher vor Verwendung richitg 
initialisiert wird. Das da an Anfang wirres Zeug drin steht, ist völlig 
normal. Nicht umsonst wir bei C die .bss-Sektion erstmal mit '0' 
gefüllt.

Jens

Jens schrieb:

> Was sollte der Verwendung entgegen stehen?
> Jeder PC arbeitet mit dynamischen Speicher.

Tja, nur haben Compiler sowas wie ein _INIT_GLOBALS Section, die sehe 
ich deutlich im Startupcode wo Variablen im Ram aus einer Tabelle im Rom 
geladen werden. Alles was als static markiert wurde und einen Startwert 
hat wird da geladen. Und zu dem Zeitpunkt gibt es noch kein SDRAM, d.h. 
die Adressen zeigen ins Leere, was vermutlich eine CPU Exception 
auslösen wird. Mich hat ja schon stutzig gemacht dass ich den SDRAM 
Berich mit dem Debugger nicht sehen kann. Die eingeschrieben Werte aus 
dem programm sind nicht zu finden.

Christian J. schrieb:
> Tja, nur haben Compiler sowas wie ein _INIT_GLOBALS Section, die sehe
> ich deutlich im Startupcode wo Variablen im Ram aus einer Tabelle im Rom
> geladen werden. Alles was als static markiert wurde und einen Startwert
> hat wird da geladen.
Alles richtig. Deshalb muß die SDRAM-Initialisierung mit in den 
Startup-Code und zwar logischerweise vor dem Kopieren der Variablen.

Jens

Jens schrieb:

> Alles richtig. Deshalb muß die SDRAM-Initialisierung mit in den
> Startup-Code und zwar logischerweise vor dem Kopieren der Variablen.

Schonmal gesehen wie der Memory Controller in C behandelt wird? 10.000 
kryptische Einstellungen? Ich werde den nicht ernsthaft in ARM Assembler 
schreiben, da ich davon keine Ahnung habe (und nicht haben will).

Aber scheinbar ist das der einzige Weg .... oder man verwendet die 
Section wirklich nur nach dem Init() lokal und nicht als globale 
Variable. Ich werde mal ausprobieren wie es mit dem Heap ausschaut ob 
man den dorthin bugsieren kann.

Danke!

Hi Uwe,

nach ein wenig rumbasteln ist jetzt klar, dass es funktioniert, wenn man 
Sections definiert und in Main dann den Init setzt. Das SDRAM ist nur 
laaaaaangsam, 8Mb vollzukritzeln dauert schon ein paar Sekunden. Aber 
was macht das schon wenn man volle 8MB an einen uC hat! Das ist wie 
Weihnachten.
Wenn ich so dran denke, dass ich vor 4 Wochen noch von Nix ne Ahnung 
hatte bei dem Board :-) und jetzt steht schon eine UART mit Terminal für 
Ausgabe, ein Ringpuffer, ein fertiges Template für EmBlocks....

Emblocks ist echt klasse, komme ich 10mal besser mit klar als mit 
CooCoxKrampf.  Für das das Debuggen im RAM zur Schonung des Flash auch 
ein Setup gebaut und nur noch 1 Mausklick dafür.

Ich habe die Libs von Majerle genommen (bitte nicht böse sein :-), der 
füllt auch nur die Structs und ruft Init dann auf und die wiederum rufen 
fmc.c auf.

1

/* 1 clock cycle = 1 / 90MHz = 11.1ns */

2

  FMC_SDRAMTimingInitDef.FMC_LoadToActiveDelay    = 2;

3

  /* TXSR: min=70ns (7x11.10ns) */

4

  FMC_SDRAMTimingInitDef.FMC_ExitSelfRefreshDelay = 7;

5

  /* TRAS: min=42ns (4x11.10ns) max=120k (ns) */

6

  FMC_SDRAMTimingInitDef.FMC_SelfRefreshTime      = 4;

7

  /* TRC:  min=70 (7x11.10ns) */

8

  FMC_SDRAMTimingInitDef.FMC_RowCycleDelay        = 7;

9

  /* TWR:  min=1+ 7ns (1+1x11.10ns) */

10

  FMC_SDRAMTimingInitDef.FMC_WriteRecoveryTime    = 2;

11

  /* TRP:  20ns => 2x11.10ns */

12

  FMC_SDRAMTimingInitDef.FMC_RPDelay              = 2;

13

  /* TRCD: 20ns => 2x11.10ns */

14

  FMC_SDRAMTimingInitDef.FMC_RCDDelay             = 2;

15

16

* Send the command */

17

  FMC_SDRAMCmdConfig(&FMC_SDRAMCommandStructure);

18

19

  /* Set the refresh rate counter */

20

  /* (7.81 us x Freq) - 20 = (7.81 * 90MHz) - 20 = 683 */

21

  /* Set the device refresh counter */

22

  FMC_SetRefreshCount(680);

Ob man da noch was opmieren kann weiss ich nicht. Die Werte sind 
sicherlich auch irgendwo abgeschrieben.

Linker Script:

Ganz sicher bin ich mir hier nicht, das ist nur intuitiv, weil anderes 
auch so gemacht wurde. Kenne die Syntax eines Linker Scripts leider 
nicht.


MEMORY
{
    ROM  (rx)   : ORIGIN = 0x08000000, LENGTH = 0x00200000
    CCRAM (rwx) : ORIGIN = 0x10000000, LENGTH = 0x00010000 /* 16kb */
    RAM (rwx)   : ORIGIN = 0x20000000, LENGTH = 0x00030000 /* 192kb */
    SDRAM (rwx) : ORIGIN = 0xD0100000, LENGTH = 0x00400000 /* 8 MB */
}

später:

    /* 8MB SDRAM Chip */
    .sdram (NOLOAD):
    {
        . = ALIGN(4);
        *(.sdram)
    } > SDRAM

Hi Uwe,

habs schon bemerkt, ja das habe ich rauskorpiet. Ich benutze deine Libs 
ja noch nicht, daher brauche ich das mit dem Display derzeit auch nicht. 
Man muss sich wohl entscheiden zwischen Deinen und denen von Majerle, 
sind beide sehr ähnlich.

Übrigens seltsame Kiste mit dem Startup Code. Der von Emblocks war nicht 
release fähig... Ich habe deinen reinkopiert ohne nachzudenken und er 
spielt. Ist aber eben ein C File und kein .s File wie vorher. Das 
eröffnet natürlich auch neue Möglichkeiten, wie Speicher Init usw. Die 
Init des SDRAM werde ich da auch reinnehmen. Nutze derzeit die von 
Majerle. Routinen sind die gleichen wie bei dir.

Stellt sich allerdings die Frage wie man die Routine von clive1 
einbindet. Sie enthält keinerlei inlcude Files und ist so nicht 
kompilerbar.

Habe sie beide mal angehängt, vielleicht kannst du ja eine draus machen, 
die fehlerfrei durchkompiliert.

Gruss,
Christian

Christian J. schrieb:
> könnte mir jemand mal in einfachen Worten und mit Beispiel erklären wie..

Nö.
Mit einfachen Worten ist das Ganze nicht erreichbar. Du mußt dich schon 
selber mit der Materie befassen, sonst wird da nix. Zuerst, wie der 
externe Busanschluß ei deinem µC konkret aufgebaut ist und wie er 
eingerichtet wird. Dann, was für ein SDRAM tatsächlich dranhängt und wie 
dieser RAM zu initialisieren ist, also vor allem Organisation und 
Blockgrößen.

Ich hänge dir mal ein Beispiel dran. Das ist zwar für einen 32 Bit 
breiten SDRAM und für einen LPC2478, aber das Wesentliche kannst du dir 
dort abgucken.

W.S.

Uwe B. schrieb:

> also die komplette Funktion "void SystemInit_ExtMemCtl(void)"
> durch die von Clive ersetzen

Hi,

Habs mir grad mal von zu hause aufs Handy geladen. Fragt sich nur ob 
diese Funktion explizit aufgerufen werden muss, zb aus dem Startup Code 
oder ob sie durch geheime Mechanismen schon aufgerufen wird.

Was ich etwas vermisse ist ein ausführliches Map File. In dem vom GCC 
steht viel drin aber das vom SDCC ist deutlich übersichtlicher.

Ich melde es später mal nach dem Sport was draus geworden ist.....

PS:

Es funktioniert nicht mit der clive1 Routine. Durchlaufen wird alles 
aber beim ersten Zugriff auf das SDRAM klebt er im Exception Handler 
drin.... erst der ausdrückliche Aufruf von TM_Init_SDRAM() lässt es 
laufen.

edit 10 Minuten später: geht doch, Fehler beim Copy & Paste.

Puh, na, also....

PS: Wenn es mal regnet und Du Langeweile hast, schreib deinen Pac Man 
doch mal auf Autoplay um (aber nicht schummeln) oder so, dass die 
Geister einen sehen müssen damit sie die Spur aufnehmen können. So wie 
in einem echten Labyrynath auch.