Linker scripts are wrong as they place SRAM into DTCM regions.

[matoushybl]

The linker scripts mark start of the RAM to 0x2000000 which is where DTCM is placed, for example for the STM32F767, the SRAM1 starts at 0x2002000 and then there is the small SRAM2 further in the memory. This way the data is placed in the wrong memory region and also a significant portion of SRAM is unused.

So if the DTCM can be used as a regular RAM, the sizes should be expanded accordingly, or the start of the RAM region should be moved to the correct SRAM addresses. As of now I propose fixing the addresses to match SRAM.

Can some of the community's embedded wizards please maybe shine a bit of light into the correct mapping? @japaric @jonas-schievink Thanks!

[bbrown1867]

I imagine the linker scripts were written this way for simplicity - viewing SRAM as one contiguous blob. Perhaps enumerating the different SRAM bank types could allow for more advanced placement of data, but I can't think of an example...when would the DTCM region not be used as "regular" (stack/bss/data/heap) RAM?

[matoushybl]

I am not really sure as I am not that experienced developer. However, some quick search showed problems with DMA and ethernet peripherals. E.g. here https://community.st.com/s/article/FAQ-Ethernet-not-working-on-STM32H7x3 .

[bbrown1867]

Interesting, thanks for providing some context! This does seem like a more advanced use case.

My concern is that if the linker scripts were changed to enumerate the different banks and place different regions into these banks, a user may run out of RAM quickly and not understand that other regions are available. Maybe there is a way to avoid that though with the linker file or build.rs.

[systec-ms]

This was fixed in https://github.com/stm32-rs/stm32f7xx-hal/pull/156, so the issue could probably be closed.

[hannobraun]

Thanks, @systec-ms.