qspi data not compiling

[MMARI.1]

hi,

I am trying to external loader connect with stm32h723zgt6 + w25q128 .

before loading  the stldr file into debugger  i need know why cube ide not compiling the data into qspi location ? 

In the main.c file constant data  has been declared as below .

const __attribute__((section(".extFlash"))) uint8_t buff[] = "Hello world from H723 QSPI";

In the flash id file has been modified as below.

QSPI_FLASH (r) : ORIGIN = 0x90000000, LENGTH = 16M 


.extFlash :
 {
 *(.extFlash) 
 } >QSPI

 after compiling why memory details not showing in the below menu 

 

[mƎALLEm]

hello,

Try:

uint8_t buff[] __attribute__((section(".extFlash")));

[MMARI.1]

hi,

i have modified as below : 

uint8_t buff[] __attribute__((section(".extFlash")))= "hello world";

 but still problem continues as same !. it not showing as earlier attached picture 

[unsigned_char_array]

Have you refreshed the build analyzer? Sometimes it doesn't refresh on its own. Rebuild and click the refresh icon:

 

Also, why did you remove const? You cannot put a variable in ROM, only constants. The linker won't like it. And if it somehow builds you will get a hardfault error if the MCU tries to modify the object.

Is the object used? If not, it might be optimized away by the linker.

[MMARI.1]

hi,

i have modified constant as below 

const uint8_t buff[] __attribute__((section(".extFlash"))) = "Hello world from H723 QSPI";

 i have refreshed many times and build the  project many times but problem is same as continues. 

[mƎALLEm]

Did you use it in your application or you've only declared it? it could be optimized by the tool if you didn't use it.

If you put buff in the live expression are you able to see the content?

 

[Tesla DeLorean]

The linker will do dead-code elimination based on what's called and what's used.

You can use the KEEP() directive in the linker script

https://github.com/cturvey/stm32extldr/blob/main/ExternalLoader_H5.ld#L43

.extFlash :
 {
 *(.extFlash)
 *(.extFlash*) 
 } >QSPI

This will address .extFlash.xxx .extFlash.yyy naming, say the compiler's using a "section per function" directive to give fine grain granularity to cherry picking what blocks of code are dependent in the dead-code removal, when dealing with .C files in similar ways to .A/.LIB