compiler generating bad .elf file

Intector · ‎2025-02-10

Hello STM,

I noted that the compiler generated a bad .elf file using an STM32H7R3L8H6H MCU. I made a small demo project(attachment) that demonstrated the problem.

I'm using an external PSRAM with HEXASPI on XSPI1 port. I reserved a place on fixed addresses in the PSRAM where I placed my buffer.

This is the definition in the linker script:

/* ========================================================================= */
/*   USER-PSRAM section definitions                                          */
/* ========================================================================= */

    .user_psram_sec 0x90000000 :
    {
        /* ----- USER_PSRAM_MEM_01 - 10240 Bytes ----- */
        . = ABSOLUTE(0x90000000);
        *(.USER_PSRAM_MEM_01)

        /* ----- USER_PSRAM_MEM_02 - 40960 Bytes ----- */
        . = ABSOLUTE(0x90002800);
        *(.USER_PSRAM_MEM_02)

        /* ----- USER_PSRAM_MEM_03 - 10240 Bytes ----- */
        . = ABSOLUTE(0x9000C800);
        *(.USER_PSRAM_MEM_03)

    } >USER_PSRAM

This is the definition for the buffer in main.c:

static UCHAR user_psram_mem_01_buffer[USER_PSRAM_MEM_01_POOL_SIZE] __attribute__((section(".USER_PSRAM_MEM_01")));
static UCHAR user_psram_mem_02_buffer[USER_PSRAM_MEM_02_POOL_SIZE] __attribute__((section(".USER_PSRAM_MEM_02")));
static UCHAR user_psram_mem_03_buffer[USER_PSRAM_MEM_03_POOL_SIZE] __attribute__((section(".USER_PSRAM_MEM_03"))) ;

I can compile the program without error, but the download will fail. I tried using the STM32CubeProgrammer, but I got the same results.

Here is a screenshot from the download in the programmer:

I'm not 100% sure, but it looks like it ties to writing my byte buffer into the flash memory instead of 0x90000000.

The STM32H7RS series MCUs seem to be very powerful devices, but I'm beginning to understand why few people use them. It's simply not worth the hassle. Who in their right mind wants to become a volunteer bug-finder for STM?

You know, Microsoft came up with a slogan once. It goes something like this:

"Knowledge shared is knowledge squared."

STM could introduce the "Bug Finder Badge."

OK, guys, keep hunting those bugs, and don't forget:

"Always be yourself unless you can be a pirate. Then always be a pirate."

KnarfB · ‎2025-02-10

[Edited, my original attempt didn't survive a clean build]

Not sure what you see here. The .list file looks okay as it loads the 0x90000000 address in line 700003d4:

	  user_psram_mem_01_buffer[Idx01] = 0x00;
700003d4:	4a13      	ldr	r2, [pc, #76]	@ (70000424 <main+0x68>)
700003d6:	687b      	ldr	r3, [r7, #4]
700003d8:	4413      	add	r3, r2
700003da:	2200      	movs	r2, #0
700003dc:	701a      	strb	r2, [r3, #0]
...
70000424:	90000000 	.word	0x90000000
70000428:	90002800 	.word	0x90002800
7000042c:	9000c800 	.word	0x9000c800

> writing my byte buffer

There is nothing to write here, it's data space.

And, it will not be initialized like normal global variables (in .data or .bss)

Did you have highest verbosity set in the above screendump?

hth

KnarfB