Can the external SDRAM address 0xD0000000 be changed ?

[Eric Lin]

Hi, there

I am studying the sample codes : STM32F429I_Discovery_FMC_SDRAM and was wondering if the starting address of the SDRAM 0xD0000000 can be changed to something else. I don't see SDRAM memory section in the linker file and don't find any SDRAM registers that can be used to save the address of 0xD0000000.

Eric

[Tesla DeLorean]

There are two possible decode banks 0xC0000000 and 0xD0000000 for the SDRAM off the FMC. The STM32F429I-DISCO is wired as the second bank. The FMC may have some additional bank swapping options, been a while since I looked.

Why would it need to be at a different address?

The linker script probably doesn't describe it because it doesn't come up initialized, the pins, controller and bus must be set up first, preferable in the SystemInit() function, or the call tree there. I would tend to commit it to the heap, and malloc() it from there.

[Eric Lin]

Thank you for your response.

I am just curious why it is 0xD0000000. Now, to commit it to the heap, how would I actually do that ? I took a look at the startup-***.s file and didn't find any related setup on the heap.

Google didn't help me much.

Thank you.

Eric

[Tesla DeLorean]

The Reference Manual should provide details of the decode map within the ARM's 4GB address space, there are four regions within 0x60000000 for the NAND, NOR, SRAM type devices, and the SDRAM has 0xC0000000, 0xD0000000. Why the voids? Well the address decode is easier this way and requires less logic and complication.

In the Keil/MDKARM startup.s the size of the HEAP is described, the scatter file could then be modified proving for an SDRAM region in the 0xD0000000 address of the 8MB provided by the memory, and the HEAP section directed there in. Similar things could be done with GNU/GCC linker scripts, or IAR .ICF files.

[Tesla DeLorean]

https://community.st.com/s/question/0D50X00009XkgXmSAJ/stm32f429idisco-sdram-initialization-in-systemstm32f4xxc

[Eric Lin]

Thank you again.

I use Atollic Truestudio and didn't find any related setup in the startupxxx.s or the linker script.

Maybe I just need to look carefully again.

Eric

[Tesla DeLorean]

For GNU/GCC you're going to need to add an SDRAM section in the .LD linker script.

You're also going to need to reimplement the _sbrk allocator in syscalls.c so it understands the heap's scope is within the SDRAM, and not between the top of your regular SRAM and under the stack. You don't want the stack in SDRAM because it is slower and a stack in it will penalize everything.

https://community.st.com/s/question/0D50X00009XkXVrSAN/stm32-linker-how-to-use-sbrk-function

The reason I suggest it for the HEAP is that it is not initialized, and even if you don't typically do or like dynamic allocation one can use it to make one time initializations in your init code for things like large arrays or frame buffers in place of large global static allocations. Having the bases of these things as pointers should be really simple to factor into your code.

[Eric Lin]

Are you suggesting that I should initialize the SDRAM in System_Init() function, and then maybe I can the linker script to define a memory section and use it as heap ? such as _user_heap_stack ?

[Tesla DeLorean]

The preferred CMSIS model would be to initialize it via a call within SystemInit()

I'm suggesting the HEAP goes into SDRAM, and the STACK goes into SRAM (internal SRAM, or CCMRAM)

A STACK in SDRAM will be unnecessarily SLOW and impact the performance of your entire code/product...

[Eric Lin]

I found this thread, which gives the details of placing heap in the external SDRAM. It has everything you said in it. Thank you for your time on this. I learned and enjoyed it.

http://www.openstm32.org/forumthread2017