Senior

Question

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

Forum|Forum|2 years ago
November 29, 2023
15 replies
5324 views

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?

STM32CubeProgrammer

This topic has been closed for replies.

KDJEM.1

ST Technical Moderator

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

To give better visibility on the answered topics, please click on "Best answer" on the reply which solved your issue or answered your question.

SouthbranchAuthor

Senior

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

ST Technical Moderator

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

To give better visibility on the answered topics, please click on "Best answer" on the reply which solved your issue or answered your question.

SouthbranchAuthor

Senior

Thanks,

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

KDJEM.1

ST Technical Moderator

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

To give better visibility on the answered topics, please click on "Best answer" on the reply which solved your issue or answered your question.

Tesla DeLorean

Guru

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

Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..

Tesla DeLorean

Guru

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
...

Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..

SouthbranchAuthor

Senior

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

Guru

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.

Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..

waclawek.jan

Super User

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

SouthbranchAuthor

Senior

Thanks I'll keep digging,

Interesting remark about the StorageInfo not being used by loader

SouthbranchAuthor

Senior

Yes, Debug -Og has been tested,

It does works but with same poor performance as standard Debug

Sign up

Click below to sign in

Login to the community

Click below to sign in