Look at file RIOT/cpu/stm32/stm32_mem_lengths.mk
At line 153 defined “RAM_LEN = 192K”, but STM2F407 have not so much long continuously RAM, just 116+12 kbytes and 64 kbyte with separate address starting at 0x10000000.
I think this is error in .mk script.
PS
How to use RAM2 in STM32L471, this parameter defined in RIOT/cpu/stm32/stm32_mem_lengths.mk but not used anywhere, this is not a CCMRAM and this is not a backup_ram, this is just separated part of RAM how to append work with it use system building scripts.
To me this does look like SRAM1, SRAM2 and SRAM3 being layout out as contiguous memory starting at address 0x2000 0000. Maybe one of the memory regions is mapped twice, and the linker script opted to use the mapping starting 0x2000 0000 for simplicity?
Generally, it would be possible to also use non-contiguous SRAM, but that would require adapting the linker script. In addition one likely wants to register the remaining memory of each and every memory region as heap for use with malloc() and friends. When only a single contiguous SRAM region is in use, we use _sheap and _eheap to point to the SRAM not used by .data and .bss. But there also is _sheap1, … sheap4 and _eheap1, … _eheap4 that allows registering multiple heaps for when SRAM is not contiguous.
For me table 4 is not usable for STM32F407, just for STM32F42xx and STM32F43xx series.
stm32_mem_lengths.mk file has error in ram length definition for stm32F407
error in ram length definition for stm32F407 at stm32_mem_lengths.mk file
...
else ifeq ($(STM32_FAMILY), 4)
ifeq ($(STM32_MODEL), 401)
ifneq (, $(filter $(STM32_ROMSIZE), B C))
RAM_LEN = 64K
else ifneq (, $(filter $(STM32_ROMSIZE), D E))
RAM_LEN = 96K
endif
else ifneq (, $(filter $(STM32_MODEL), 405 407))
RAM_LEN = 192K
...
must be changed like this:
...
else ifeq ($(STM32_FAMILY), 4)
ifeq ($(STM32_MODEL), 401)
ifneq (, $(filter $(STM32_ROMSIZE), B C))
RAM_LEN = 64K
else ifneq (, $(filter $(STM32_ROMSIZE), D E))
RAM_LEN = 96K
endif
else ifneq (, $(filter $(STM32_MODEL), 405 407))
RAM_LEN = 128K
...
Be the change you want to see and create a PR
This is indeed a bug, the CCM RAM is not continuous with normal RAM.
I have a branch to enable the CCM as an extra heap, but I didn’t PR it yet as it just unconditionally enables the CCM clock and thus uses energy even when not used.
But in general CCM should be faster than normal RAM, so it could be preferential to allocate some system resources there.