I have been using a linux script generated CRC code instered into a HEX file on some other STM32 products. I am now implementing this for the STM32G431. The GUI is the 1.3.0 IDE. This has changed the debug config.

[rclar.6]

I want to specify the HEX file for data into the STM32 and the elf file for symbols used in the debugger. The User interfec has changed though and I seem to only be able to get one or the other (i.e. just the hex or just the elf).

This is a necessary operation as safety critical software need to be able to verify PROM contents

using a CRC32 generated off the target processor. Here is the modified 1.3.0 gui entry for the debugger

[berendi]

> I want to specify the HEX file for data into the STM32 and the elf file for symbols used in the debugger. The User interfec has changed though and I seem to only be able to get one or the other (i.e. just the hex or just the elf).

I can't see what's the problem with it. Yes it is supposed to flash the hex file, and consult the elf file for debugging symbols.

Do you perhaps mean that the hex file contains only the crc, and you'd rather want to flash both of them? In this case, enable generating a hex file from elf under Project / Properties / Settings / MCU Post build outputs, then concatenate the two hex files, dropping the last line (EOF marker) from the first one.

[rclar.6]

the hex file I have is created in the post build process. It converts the elf to bin and then calculates the CRC. It then creates a hex file and changes the

location with the CRC for the calculated one. This script has been fine with other STM32 processors. The only change I can see is the GUI and the fact I am using an STM32431 not an STM32F series.

[berendi]

OK, and what is the problem?

[rclar.6]

Will try this

[berendi]

Does it happen when you load the hex file generated by CubeIDE post build options too?

[rclar.6]

AH Ok just tried this. Loaded symbols from elf and data from hex file. Worked as expected.

I think I must have something going on with srec_cat and the hex file.

This did work from the stm32F processors but maybe its the data length per line or something.

Thanks.

[rclar.6]

OK using the hex file made by the IDE/compiler and the lef file for symbols works.

The hex files were were generating (with srec_cat) for STM32F projects did work.

I notice though that the STM32 tools generate hex file with a length of

0x10 bytes whereas the srec_cat gives line lengths of 0x20. Probably a clue.

But at least I have something to go on now. Thanks for the suggestion

[berendi]

I'd rather suspect the elf-to-bin conversion process, it might look for the wrong elf section names, attributes, whatnot, and just happen to work on your old toolchain.

Check that the script is using objdump from the current toolchain, not the old one.

Or you can let CubeIDE handle the "converting elf to bin" part, skipping it in the script.

[rclar.6]

I think it must be the elf to bin process, as the hex file produced by the compiler and linker

works. It just has a data 'hole' in it. When the elf or the hex file is used the location 0x080001D8

and 0x080001DC contain 0xFFFFFFFF.

When the BIN file derived hex files are used they place zeros here and the debugger, for some reason, ends up being fed

a negative address.

$srec_info hex_from_compiler.hex -intel

Format: Intel Hexadecimal (MCS-86)

Execution Start Address: 080005C1

Data:  08000000 - 080001D7

       080001E0 - 0800810F

OK half way to solving this now!

[rclar.6]

I got the compiler/linker to generate a hex file and now ignore the binary it produces.

Using

 srec_cat mss.hex -intel -fill 0xFF 0x08000000 $CRC_ADDR -o mss.hex -intel -Output_Block_Size 16

It now pads this correctly. The crc32 I get from srec_cat now agrees with the ones generated on the STM32G431.

Thankyou berendi!