2025-03-05 11:33 PM
Hi there,
With STM32CubeIDE v. 1.18.0 there comes new GNU tool ver. 13.3
My linker script defines between others:
RAM_D3 (xrw) : ORIGIN = 0x38000000, LENGTH = 64K
This area is used explicitely for BDMA
/* RAM D3 for BDMA access */
.ramd3 (NOLOAD) :
{
. = ALIGN(4);
_sramd3 = .; /* create a global symbol at data start */
. = ALIGN(4);
_eramd3 = .; /* define a global symbol at data end */
} >RAM_D3
In the code, there is only one array assigned to above mentioned section:
// ADC3 thru BDMA
uint32_t adc3_data[4] __attribute__ ((section (".ramd3")));
After the build it is easy to find in *.map file that adc3_data is correctly placed at 0x38000000 address and BDMA can access the data. Build Analyzer shows the same:
.ramd3 0x38000000
And it was normal and expected behaviour until GNU Tools 12.3 (included).
Just with GNU 13.3 is works no more.
The same code and linker script result with faulty date placement!!!
In the *.map file one can see wrong placement:
.ramd3 0x240008d0
BTW With GNU 13.3 there comes newlib 4.4.0 but no one has mentioned in release notes about it.