STM32H750IB_flash.lds does not have RAM_D2_DMA section

Hardware Development
1

Hello all,

I’m reading through the info on making a custom bootloader and I started digging into the .lds files in the core directory.

When looking at the memory section I noticed that:
STM32H750IB_flash.lds Does not have:

RAM_D2_DMA (RWX) : ORIGIN = 0x30000000, LENGTH = 32K

From: [QSPI]( libDaisy/STM32H750IB_qspi.lds at master · electro-smith/libDaisy · GitHub)

MEMORY
{
	FLASH (RX)    : ORIGIN = 0x08000000, LENGTH = 128K
	DTCMRAM (RWX) : ORIGIN = 0x20000000, LENGTH = 128K
	SRAM (RWX)    : ORIGIN = 0x24000000, LENGTH = 512K
	RAM_D2_DMA (RWX) : ORIGIN = 0x30000000, LENGTH = 32K
	RAM_D2 (RWX)  : ORIGIN = 0x30008000, LENGTH = 256K
	RAM_D3 (RWX)  : ORIGIN = 0x38000000, LENGTH = 64K
	ITCMRAM (RWX) : ORIGIN = 0x00000000, LENGTH = 64K
	SDRAM (RWX)   : ORIGIN = 0xc0000000, LENGTH = 64M
  QSPIFLASH (RX): ORIGIN = 0x90040000, LENGTH = 7936K
}

from the [flash]( libDaisy/STM32H750IB_flash.lds at master · electro-smith/libDaisy · GitHub)

MEMORY
{
	FLASH (RX)    : ORIGIN = 0x08000000, LENGTH = 128K
	DTCMRAM (RWX) : ORIGIN = 0x20000000, LENGTH = 128K
	SRAM (RWX)    : ORIGIN = 0x24000000, LENGTH = 512K
	RAM_D2 (RWX)  : ORIGIN = 0x30000000, LENGTH = 288K
	RAM_D3 (RWX)  : ORIGIN = 0x38000000, LENGTH = 64K
	ITCMRAM (RWX) : ORIGIN = 0x00000000, LENGTH = 64K
	SDRAM (RWX)   : ORIGIN = 0xc0000000, LENGTH = 64M
    QSPIFLASH (RX)  : ORIGIN = 0x90000000, LENGTH = 8M
}

Is there are reason the flash version does not have the DMA section?

Thanks,
Brett

2

The SRAM and QSPI linkers represent an incremental improvement in this case. That region contains the sram1_bss section, which is defined as DMA_BUFFER_MEM_SECTION in libDaisy. In the original flash linker, that section is just a part of the whole RAM_D2 region.

The reason this represents an improvement is that only the first 32k of that region is configured as non-caching (which is necessary for DMA). If you were to place too many items there, the region would overflow and you’d get a compilation error. In the flash version, you’d likely end up with a very tricky to debug issue.

I think we simply didn’t bring that change back to the flash linker. It may be worth creating an issue or a PR for it. Luckily, it should not be a breaking change unless someone is parsing the compiler’s output.

3

@Corvus_Prudens ,
Thank you - that makes sense… I can open a issue on it, I just through i’d check before I did.

Thanks,
Brett