Does Cube-IDE support launching executables that aren't ELF?

[n2wx]

An oldie but still needed, CRC in the last word of the FLASH segment. So I'm fine up until I get to the point when I tell TrueStudio my application is other than an .ELF because at Properties / Run/Debug Settings/ Edit / TrueStudio is hobbled by supporting only elf applications.

Does Cube-IDE remove this limitation or is it also handicapped by an inability to launch anything but .elf files?

I suspect the answer is no because ST. But might as well ask, maybe a miracle happened.

There's a taunting file - STM32Cube_FW_ClassB_V2.3.0 - with examples for IAR, Keil, and even System Workbench. Nada for ST's own product. It's like every time I turn around ST shoots me in the head. Thanks guys! Keep pushing me back to windows.

EDIT so someone else already dealt with this and posted a solution to the elf problem here https://community.st.com/s/question/0D50X0000AlflsxSQA/how-to-convert-hex-file-to-elf-file .

[waclawek.jan]

I use objcopy with --update-section to insert the calculated checksum(s) into the .elf.

I loathe eclipsoids but this is a normal part of post-link script if they enable to do something like that.

JW

[n2wx · Accepted solution]

This sounds absolutely perfect because it'll preserve the debug symbols.

I've added a new section "CRC" that sits at the end of the existing FLASH section. Is that close to what you're doing?

May I ask what file format your CRC is in? Is it like a mini .elf file or a .hex with the CRC? And are you finding the debug symbols from the original elf are preserved with your approach?

> I loathe eclipsoids but this is a normal part of post-link script if they enable to do something like that.

Affirmative on the loathing. Every new guy on the block shows up with an eclipse front end and dashes all of our hopes. What surprised me was to find someone (segger) charging a fortune for their eclipse tool. I think it's just like all the others, a front end to the gnu stuff. For ST this is now two elipses in a row and the third will not be a charm.

[n2wx]

Fortunately it replaces the section but unfortunately it's not inserting the CRC. I'm not sure where it got whatwhat it put in there, no permutation of the CRC I could think of turned the CRC into what it put there. Arrrrgh! Otherwise I think your answer is the best for these eclipses. Man I hate eclipse

[Tesla DeLorean]

As this is semi-related, and someone tickled the length/crc thread

/* End section */

 . = ALIGN(4);

 .endof :

 {

 /* This is used by the startup in order to find the end */

 _limit_flash = .;   /* define a global symbol at the end of flash */

_flash_size = _limit_flash - g_pfnVectors; /* compute length based on beginning and ending points */

 } >FLASH

startup.s

...

.word UsageFault_Handler

.word _limit_flash - g_pfnVectors /* compute size */

.word 0

.word 0

...

I'd original tried this, but the GNU Linker bollixes it up

.word _flash_size /* symbol you define in .ld linker script */

https://community.st.com/s/question/0D50X0000Awa25q/generated-binary-file-size-in-stm32l4

https://community.st.com/s/question/0D53W000004HGN7SAO/crc-calculation-using-sreccat

[waclawek.jan]

I use a binary file containing just 4 bytes of CRC. It's generated by some srecord-fu, but I use homebrew single-use utilities for similar purposes, too.

Snippet from my makefile:

%.elf: $(ELF_PREREQUISITES)

#worst_forum_software_ever: this idiotic editor does not preserve tabs nor spaces, when it guesses it ought to do so [linking, then generation of the $*.crc.bin file, etc.]

   $(OBJCOPY) $@ --update-section .crc_x=$*.crc.bin $@.tmp

   $(COPY) $@.tmp $@

   $(REMOVE) $@.tmp

I'm no make/scripting guru so it's quite clumsy.

JW

[Pavel A.]

IMHO it's not a problem at all to add the CRC to the image. The problem is, how the bootloader, or whatever code that checks the CRC, finds it and the length of the chunk to verify.

After using several variants, stopped on the one proposed by @Piranha : reserve 512 bytes from the image base (because of VTOR alignment requirement) and keep there all the image info: size, CRC, versions and so on.

Among other variants probed were:

• Append the CRC after image end, and find it by scanning for first word from the area end not equal to FFFFFFFF.
• Insert the info block at negative offset from the reset address (which is vectors[1])

Every toolkit can generate a bin file.

Once you get the bin file, you can do anything - checksum, patch, append, prepend... with a simple C program.

Or a Python script. Or a Ruby script.

It is as simple as open a file, get its length, calculate the CRC, poke the result back into the file (or create a new file).

Much simpler and flexible than other things mentioned in this thread.

The only remaining issue is the subject of this thread - how to debug the resulting binary and bring the symbols from the original .elf file.

-- pa

[waclawek.jan]

> It is as simple as open a file, get its length, calculate the CRC, poke the result back into the file (or create a new file).

> Much simpler and flexible than other things mentioned in this thread.

> The only remaining issue is the subject of this thread - how to debug the resulting binary and bring the symbols from the original .elf file.

I do the same "much simpler and flexible" CRC calculation from the bin (or hex, I don't remember which one exactly, but that's the same simple thing - well certainly for srecord, and it's the same also for old fashioned Pascal and C, maybe not so much for Python and Ruby... ;) ), then push back the result not into the bin but directly to elf as I wrote above.

I don't see how is it a problem, but maybe that's because I'm too old fashioned to python and ruby and cuben.

JW