STM32F7 DISCO - memory sections

[benny]

Posted on August 24, 2015 at 13:51

Hi all,

I have a question about the different memory sections. I use a modified version of the demonstration project.There are 4 memory sections:SRAMSDRAMFlashNOR (QSPI)This code save the variable to NOR:#if defined ( __ICCARM__ ) #pragma location=''ExtQSPIFlashSection''#else __attribute__((section(''.ExtQSPIFlashSection'')))#endifSo now my Questions. 1) How do i know where everything else is stored? I think const variables are stored in Flash and everything else in SRAM. But the SRAM-HAL-Header isn't used in this project. So my variables are stored in SDRAM?2) And what happen if i create a new variable with malloc?3) There is a function to get the free size of memory?Thanks everyone!For ST:I have 2 wishes for a new Rev. of the STM32F7 DISCO.- place a empty (header-) connection with a solder bridge to connect a battery for the RTC- some more empty connections for another ADC (now i can only use ADC 3 over Arduino Pins)But it's still a great board!

[Tesla DeLorean]

Posted on August 24, 2015 at 17:14

IAR would direct memory content via .ICF file (linker script / scatter file in other tools) or GUI settings. This should describe the memory locations, and sizes, and name.

Review the .MAP file to see where the linker has actually placed things.External memories would need to be configured (usually via SystemInit) *before* the C runtime startup code can move data in SDRAM, etc. The Internal SRAM functions at reset, so doesn't need extra configuration.In Keil we'd create a HEAP section, usually in startup_stm32f7xx.s, with the size/section name, and a scatter file would determine if the heap is located in SRAM or SDRAM. The malloc() function draws from this pool, you define the size of the pool, but there are explicit functions to tell you how much free space there is, and this space may be non-contiguous. When I need to check these things I'd walk the allocators internal structures within the memory arena. If there isn't space malloc() will return NULL

[benny]

Posted on August 24, 2015 at 17:48

Okay. Thank you. I will check these files.

[Nesrine M_O]

Posted on August 24, 2015 at 17:53

HiNyix,

1/You may refer to your linker file: Any RO file (.c) tagged by:

#if defined ( __ICCARM__ )
#pragma location=''ExtQSPIFlashSection'' 
#else
__attribute__((section(
''.ExtQSPIFlashSection''
)))
#endif

It is placed in QSPI flash (0x90000000) else it is placed in flash memory. 2) And what happen if i create a new variable with malloc? Your variable will be allocated in Heap section , in fact the malloc function returns a pointer to the allocated block or a null pointer if there is not enough memory to satisfy the allocation request Thank you for your suggestions about STM32F7 discovery board, they are noted and will be discussed internally. -Syrine-

[benny]

Posted on August 26, 2015 at 12:38

Okay. If i get it right the heap in the demonstration project is placed in SRAM:

#if defined ( __ICCARM__ ) /*!< IAR Compiler */#pragma location=0x20006024uint8_t ucHeap[ configTOTAL_HEAP_SIZE ];#elif defined ( __CC_ARM )uint8_t ucHeap[ configTOTAL_HEAP_SIZE ] __attribute__((at(0x20006024)));#elif defined ( __GNUC__ ) uint8_t ucHeap[ configTOTAL_HEAP_SIZE ] __attribute__((section(''.RamData2'')));#endifThe MPU is also configured for SRAM:MPU_InitStruct.BaseAddress = 0x20010000;MPU_InitStruct.Size = MPU_REGION_SIZE_256KB;So i have a few more questions. If i write ''__attribute__((section(''.ExtQSPIFlashSection'')))'' at the beginning, every variable in this file is stored in NOR Flash?And there is a way to switch the Heap from SRAM to SDRAM (in demonstration project with FreeRTOS)? 

[benny]

Posted on October 02, 2015 at 16:29

I still having trouble to switch the heap to SDRAM. The EVAL Board has an example for SDRAM DataMemeory. I try to port it to my DISCO-Board in the following way:

1) Uncomment DATA_IN_ExtSDRAM in file system_stm32f7xx.c2) Add ''.equ __initial_spTop, 0x2004FFFF'' to file startup_stm32f746xx.s3) Change ''ldr   sp, =_estack'' to ''ldr   sp, =__initial_spTop'' in the same file4) Add ''ldr     r0, =_estack'' and ''msr     MSP, r0'' in the same file5) Change ''_estack = 0x2004FFFF;'' to ''_estack = 0xC07FFFFF;'' in LinkerScript.ld6) Change Memory to ''RAM (xrw)      : ORIGIN = 0xC0000000, LENGTH = 8M'' in the same fileIf i try to debug now, the following will happen:The first Function in main is MPU_Config and in this function is a struct called ''MPU_InitStruct''. The MSP and SP are at 0xC07FFFdc. The PC is at 0x800004F2.Then there is a function HAL_MPU_Disable(); which works fine. The next line is ''MPU_InitStruct.Enable = MPU_REGION_ENABLE;'' And here i can see that the struct is in Memory at 0xFDFFFFFF. And after that a error occur and takes me to an infinity loop in startup file (Default_Handler).Please help me! If you already have a working example, I would be really happy if you can share it with me.

[benny]

Posted on October 06, 2015 at 16:05

I solved this problem with the help of clive1.

You need to change 3 files to get your SDRAM working as data memory. I attached all 3 files with some comments. This example was tested with a STM32F7-DISCO board. I tried two different projects a really simple one and a fork of the demonstration project. The last one uses FreeRTOS, USB, FatFS and STemWin. Only FatFS needs a little change in the file ''syscall.c''. The function ff_memalloc and ff_memfree need to work with the RTOS and you need to replace the malloc and free function with pvPortMalloc and vPortFree. Remember to change the LinkerScript.ld to your needs. In this example the Stack is still in the SRAM. You can change this if you uncomment two lines (around line 120, see comments there). After that the Stack is placed in SDRAM too. But this will slow down your device more. I also want to say that the example from STM32F7-EVAL -> Examples -> FMC -> DataMemory only works under certaincircumstances. Because the SDRAM is initialized after .data and .bss sections are created. You should fix this like in my attached file. Thank you again to clive1. ________________ Attachments : SDRAM_DataMemory.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006Hzjg&d=%2Fa%2F0X0000000bOq%2Fw5Th7FhiekYAPYOL_xhUdEv.coiNXpuxdPLZVS4kzUI&asPdf=false

[benny]

Posted on February 06, 2016 at 22:50

I tested the Code a lot and I found a problem with the STemWin Library. STemWin uses the SDRAM as a Buffer. So it can be that the Buffer corrupt the heap in the SDRAM. At the moment I'm not sure, if i can change this because the library is closed source. So if you want to use STemWin, you can't use the SDRAM.

[benny]

Posted on November 10, 2016 at 21:36

For some interested people I will give an update.

In LCDconf.h you can define the GUI Framebuffer-Location in SDRAM. If you use 2 buffers then you can use 4 MB of the SDRAM.  So with the new Libraries (v1.4 and 1.5) and some changes to the LinkerScript it is possible to get the Heap and the framebuffer working in the SDRAM. But there are two main problems:1.) You need to rewrite sbrk() and a main part in the LinkerScript. That needs some knowledge and for me I didn't get it fully working. (see 2.)2.) Everthing will work fine except from pointer-operations, because the SDRAM is only using 16bit and the system is working in 32bit. I'm sure there is a way to fix this in the LinkerScript, but I don't know how.I think there is a much easier way. Just don't change anything and use Heap5 from the FreeRTOS. Set the Heap-Section in the LinkerScript to a value that your stack has enough memory. Now with Heap5 you can define and provide FreeRTOS memory sections without defining them in the LinkerScript. FreeRTOS will use them for the heap too. Maybe there is still the pointer problem. I didn't tested this, because I have not time. But for sure I will test it in the future. Take a look at the FreeRTOS API for Heap 5 and how to define the SDRAM section. And don't forget that you

don't

need to change your startup-files!

[Tesla DeLorean]

Posted on November 10, 2016 at 23:45

One might be able to malloc() the frame buffers. Or push them to the front or back of SDRAM so the heap is a single linear region. I did post some Keil code to add additional regions into the heap allocator's chain, allowing for sparse/discontinuous memory blocks.

Not sure I understand the 16 vs 32-bit issues. The memory bus width shouldn't preclude 8, 16 or 32-bit writes to it.