External loader in release-build is not parsing at start-up in CubeProgrammer

[Southbranch]

Hi!

The DEBUG build version of my custom loader is working but is slow, so I tried RELEASE build instead to hopefully get a smaller bin-file with a faster and more efficient execution.

However, CubeProgrammer fails at startup with a “loading-file-error-message” and in the list of loaders my loader have blank fields of memory size, page size etc (failed to parse…)

What are the reasons for this?

Any compiler settings that should be changed?

[KDJEM.1]

Hello @Southbranch ,

Which STM32CubeProgrammer version are you using?

Could you please check the memory parameters in Dev_Inf.c file.

For that, I advise you to refer to an available Dev_Inf.c file and update the device information with the correct information concerning the external memory.

Also, I think that UM2237 and precisely Developing customized loaders for external memory Section can help you.

Thank you.

Kaouthar

[Southbranch]

 

Many thanks for reaching out but it still fails..

I am using ver 2.15 (latest for now) and have previously followed all guidelines above. With RELEASE build, the size of the .stldr file comes down from around 2MB to 150KB which seems similar with other external loaders.

It’s a mystery, the DEBUG version parses and executes fine but the RELEASE fails…

 

[KDJEM.1]

Hi @Southbranch ,

The Release configuration makes the project optimized for smaller code size and with no debug information and  the Debug configuration makes the project built with debug information and without any optimization.

For that, please try to modify the optimization in the DEBUG or in RELEASE to get your project working faster.

I hope this help you!

Kaouthar

[Southbranch]

Thanks,

I basically tried all combinations of optimization but the same failing result..

[KDJEM.1]

Hi @Southbranch ,

The DEBUG build version of my custom loader is working but is slow.

Could you please try to use DEBUG with optimization level "Optimize for Debug (-Og)" as mentioned in this discussion.

Thank you.

Kaouthar

 

[Tesla DeLorean]

It could be how StorageInfo exports. Might discard the section as it's not internally referenced by anything. Should be able to see symbol, and that it's 200 bytes. Check .MAP, perhaps dump via OBJCOPY or FROMELF type tools.

Not sure if you're building for your U5 or H7 platform. I use a Linker Script like this for my stand-alone GNU/GCC build

https://github.com/cturvey/stm32extldr/blob/main/ExternalLoader_F7.ld

[Tesla DeLorean]

FromElf reports like this for a working .STLDR

========================================================================

** ELF Header Information

 File Name: MX25L6433F_STM32U535B-NUCLEO.stldr

 Machine class: ELFCLASS32 (32-bit)
 Data encoding: ELFDATA2LSB (Little endian)
 Header version: EV_CURRENT (Current version)
 Operating System ABI: none
 ABI Version: 0
 File Type: ET_EXEC (Executable) (2)
 Machine: EM_ARM (ARM)

 Image Entry point: 0x20001877
 Flags: None (0x05000000)

 ARM ELF revision: 5 (ABI version 2)

 Conforms to Base float procedure-call standard

 Header size: 52 bytes (0x34)
 Program header entry size: 32 bytes (0x20)
 Section header entry size: 40 bytes (0x28)

 Program header entries: 2
 Section header entries: 10

 Program header offset: 52 (0x00000034)
 Section header offset: 33908 (0x00008474)

 Section header string table index: 7

========================================================================

** Program header #0 (PT_LOAD) [PF_R]
 Size : 200 bytes
 Virtual address: 0x00000000 (Alignment 4)


====================================

** Program header #1 (PT_LOAD) [PF_X + PF_W + PF_R]
 Size : 12956 bytes
 Virtual address: 0x20000004 (Alignment 4)


========================================================================

** Section #1 'P3' (SHT_PROGBITS) [SHF_ALLOC]
 Size : 200 bytes (alignment 4)
 Address: 0x00000000

 0x000000: 4d 58 32 35 4c 36 34 33 33 46 5f 53 54 4d 33 32 MX25L6433F_STM32
 0x000010: 55 35 33 35 42 2d 4e 55 43 4c 45 4f 00 00 00 00 U535B-NUCLEO....
 0x000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
 0x000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
 0x000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
 0x000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
 0x000060: 00 00 00 00 03 00 00 00 00 00 00 a0 00 00 80 00 ................
 0x000070: 00 10 00 00 ff 00 00 00 80 00 00 00 00 00 01 00 ................
 0x000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
 0x000090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
 0x0000a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
 0x0000b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
 0x0000c0: 00 00 00 00 00 00 00 00 ........

 Info_BLOCK$$Limit

** Section #2 'P1-P2 ro' (SHT_PROGBITS) [SHF_ALLOC + SHF_WRITE + SHF_EXECINSTR]
 Size : 12956 bytes (alignment 4)
 Address: 0x20000004
...

[Southbranch]

 

Thanks Tesla,

I am using CubeIDE so I am not sure on how to use the FromELF tool.

I am using a H725-deive and tried to modify the F7-linker script your provided. Like your comment, my feeling is also it has do with how Dev_Inf (or StorageInfo) is stored/interpreted. 

Your script uses the first syntax below (StorageInfo) and the one I am using from this https://github.com/STMicroelectronics/stm32-external-loader/blob/contrib/Loader_Files/H7%20device/linker.ld  uses the second:

.info :
 {
 KEEP (*(.rodata.StorageInfo))
 } >RAM_INFO

.Dev_Info :
 {
 	__Dev_info_START = .;
 	*(.Dev_info*)
 	KEEP(*(.Dev_info))
 	__Dev_info_END = .;
 } >RAM_D1 :SgInfo
 

 

Also, your script uses two RAM sections versus a single section in the one I am using:

MEMORY
{
 RAM_INFO (r) : ORIGIN = 0, LENGTH = 1K
 RAM_PROG (xrw) : ORIGIN = 0x20000004, LENGTH = 128K-4 /* 0x20000004 for Non-H7, 0x24000004 for H7 */
}

MEMORY
{
 RAM_D1 (xrw) : ORIGIN = 0x24000004, LENGTH = 512K
}

 

I have tested a couple of combinations of above but so far without result.

[Tesla DeLorean]

You would likely have objcopy, I'm just less familiar with the options there.

I have two ram sections to ensure I get two distinct program headers.

Someone else was having problems with an H5 loader where sections overlapped in the memory space. The StorageInfo structure isn't used by the loader itself, but rather by the application to get the naming and geometry data. 

[waclawek.jan]

I'm not sure objcopy would be much useful in this case; I'd look at readelf or objdump rather.

Nonetheless, the question is, what to look for exactly. I don't use CubeProgrammer nor 'H5, so can't judge.

JW

[Southbranch]

Thanks I'll keep digging,

Interesting remark about the StorageInfo not being used by loader

[Southbranch]

Yes, Debug -Og has been tested,

It does works but with same poor performance as standard Debug