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?

[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

[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

[Southbranch]

Yes, Debug -Og has been tested,

It does works but with same poor performance as standard Debug

[Tesla DeLorean]

What to look for.. well in the offending case it looked like the sections described in the .ELF had memory address overlap, the code, data and bss described areas backed by physical data, or virtual lengths, and then the StorageInfo, which is not physically read or used by the loader code is parked within the file at some location that's common to the aforementioned code,data,bss. I should perhaps make a short app to demonstrate as it was hard to track

Sorry it was U5, but resulted in loader not being pulled into RAM, not that the fields in the "EL" pane were empty. I've seen that in other situations, but usually when the StorageInfo structure wasn't 200 bytes, or mapped poorly   https://community.st.com/t5/stm32cubeprogrammer-mcus/cubepogrammer-error-on-stm32u545/m-p/601928

Also the loaders I'm building don't kitchen sink the CubeMX nonsense, Interrupts, Vector Tables, startup / main.

Optimization might be an issue of moving data from memory to registers, although not sure why this would break StorageInfo.

Other considerations for "slowness", use of millisecond delays, or broken timeout loops.

The ST-LINK/V2 implementation is relatively slow due to 12 Mbps USB, the ST-LINK/V3 is orders of magnitude more efficient. Would avoid writing 64MB - 256MB via ST-LINK/V2's, you'll be there for 10's of minutes.

[Flying-Centaur]

I also had a problem where STM32CubeProgrammer was showing blank fields, zeros and UNKNOWN/UNKOWN for my external loader.  Commenting here as this was one of the places that Google highlighted.

This is with STM32CubeIDE Version: 1.16.0 for STM32U585.

In my case, Dev_Inf.c included octospi.h to have access to the memory size constants.

The auto-generated part of octospi.h includes main.h.

As I had based the external loader project on an existing cube.ioc project file and had not chopped out all the unnecessary peripherals, main.h was still including stm32u5xx_ll_dma.h, stm32u5xx_ll_lptim.h and stm32u5xx_ll_lpuart.h.  Each of these include files contains static const array declarations, meaning that any file that includes them gets a copy.

Therefore Dev_Inf.c got a copy too that was then included into the SgInfo program header by the example linker file directive ( from https://github.com/STMicroelectronics/stm32-external-loader/tree/contrib/Loader_Files/other%20devices )

.Dev_info (READONLY) :
{
KEEP(*Dev_Inf.o ( .rodata* ))
} :SgInfo

These increased the program header size from 200 bytes (0xC8):

$ objdump -p ./Debug/external_loader.elf
./Debug/external_loader.elf: file format elf32-little
Program Header:
LOAD off 0x00001004 vaddr 0x20000004 paddr 0x20000004 align 2**12
filesz 0x00025fc8 memsz 0x000265c8 flags rwx
LOAD off 0x00027590 vaddr 0x20025590 paddr 0x20025590 align 2**12
filesz 0x00000154 memsz 0x00000154 flags r--

Changing the linker directive to be more specific solved the problem:

.Dev_info (READONLY) :
{
KEEP(*Dev_Inf.o ( .rodata.StorageInfo ))
} :SgInfo

... returning the program header size to 200 bytes:

$ objdump -p ./Debug/external_loader.elf
./Debug/external_loader.elf: file format elf32-little
Program Header:
LOAD off 0x00001004 vaddr 0x20000004 paddr 0x20000004 align 2**12
filesz 0x00025fc8 memsz 0x000265c8 flags rwx
LOAD off 0x00027590 vaddr 0x20025590 paddr 0x20025590 align 2**12
filesz 0x000000c8 memsz 0x000000c8 flags r--

[Tesla DeLorean]

Thanks for the response and confirmation.

One of the cases I'd seen earlier was in loaders ST distributed for the NUCLEO GFX boards (LCD+QSPI), where the linker had shrunk the allocation, basically feeling it could fold the trailing zeros that pad the end of the structure in most instances. ie sectors and sizes details.

I've Keil's .FLM also has specific sensitivities to the size of it's information structure, and oddly with the length of the filename, which is 31 characters in the main portion. The name embedded in the structure can be much longer, but does cause difficulty in the selection dialog as the default width is unhelpfully tight.