STM32G030 Bootloader Flash Programming: Hex file as non aligned values

[DDeba.1]

Hi, 

I have a bootloader for the STM32G030 which is working good but at the end of the hex file, I get flash alignment error (PGAERR). After going deeper in the issue, I found out that the hex file produced by the STM32CubeIDE has non-aligned values. Below are the last lines of the hex file in question:

:04D69800000000008E
:04D69C00E140000861
:04D6A000B940000885
:10D6A400200000000024F400010000000400000039
:10D6B40014000020000000005CD600087CD600089E
:10D6C4003CD600080000000000000000000000003C
:10D6D4000000000000000000000000000000000046
:10D6E4000000000000000000000000000000000036
:10D6F4000000000000000000000000000000000026
:10D704000000000000000000000000000000000015
:10D714000000000010B50C4A54698023DB02234347
:10D724005361EFF3108C72B6002303E004C904C004
:10D734000133DBB23F2BF9D9034B1B69DB03FBD469
:0CD744008CF3108810BDC046002002408D
:04000005080077A5D3
:00000001FF

As you can see, the second line has an address of D69C which is 32bit aligned but not 64bit aligned as required for flash writes. Moreover, the remaining of the lines remain not 64bit aligned. Is there any solution to this? Is the only solution to make the bootloader smart enough to recognize this and use merge different hex record lines to align the 64 bit address or are there any easier solutions (such as forcing the hex generation to be 64bit aligned)

Thanks

[STOne-32]

Dear @DDeba.1 ,

The best way to handle such case, is to implement the alignement of 64bits address at the programming to side ( May be by reading back old address and to re-ajustement and program the buffer in physical address of flash ).  Can you try to check if CubeProgrammer is not implementing that already ?

Ciao

STOne-32

[Andreas Bolsch]

For that purpose "srec_cat" is a good choice. Supports Intel Hex format as well despite its name.
However, you might want to fill the padding bytes with 0xFF with objcopy's --gap-fill option.

BTW: A parser for S-Record or Intel Hex is rather simple, so ... And spitting out from memory in either format is even simpler. Hence it might be even faster/simpler to write your own tool rather than fiddling with options to objcopy, as this is buried somewhere in the IDE. As I use simple Makefiles only that's easier to tweak