STM32F411 RAM size with CMSIS and arm GNU toolchain

[Alex_F]

Hi folks.

Trying to put some debug info on MCU startup using SWO. I'm using pure CMSIS with 'STM32CubeF4 CMSIS Device MCU Component' and Arm GNU toolchain. I want to print some device info including ROM and RAM size.

ROM size was easily obtained from stm32f411xe.h as difference between FLASH_END and FLASH_BASE.

But RAM seems to be a different thing. While SRAM1_BASE is defined in the mentioned header file, the SRAM_END is somehow missing.

I was poking around searching for other way to get the SRAM END address and came across the linker file heaving _estack calculated as SRAM origin + length where both defined in linker file:

_estack = ORIGIN(RAM) + LENGTH(RAM); /* end of "RAM" Ram type memory */
MEMORY
{
FLASH (rx) : ORIGIN = 0x8000000, LENGTH = 512K
RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 128K
}

Since origin is also defined in stm32f411xe.h as SRAM_BASE, I can easily calculated the desired RAM size:

 extern uint32_t _estack;
 tick_log("MCU: SMT32F411CEU6, having %dK FLASH, %dK SRAM, running at: %u.%03u MHz.\r\n", \
 (FLASH_END + 1 - FLASH_BASE) / 1024, ((uint32_t)&_estack + 1 - SRAM_BASE) / 1024, SystemCoreClock / 1000000, SystemCoreClock % 1000000);

Now I'm wondering if there is any better way to calculate ROM and SRAM that I missed?

Thank you.

[TDK]

The flash (ROM) size can be read from the chip itself in the flash size register. But the toolchain FLASH_END will also work.

 

No better way to calculate SRAM other than what you're doing, which will work if you don't modify the startup file.

[Tesla DeLorean]

>>Now I'm wondering if there is any better way to calculate ROM and SRAM that I missed?

Perhaps knowing how much for the FLASH is actually used, and the active stack depth would be more helpful.

There should be linker symbols you can use to identify the top of the statics. The bottom of the Stack is usually used as a crude bounding limit for the Heap in ST/GNU implementations, where say _sbrk reports/checks.

If you're using dynamic memory walking the heap, via it's linked-list, might be instructive.