Bootloader cannot flash hex files with shorter lines

[FS.1]

Hi,

we have a hex file coming from GCC which we cannot flash onto the MCU with our own flashing tool (F412 and L471 tested).

While investigating, we found that after a shorter line all writing seems to fail silently (still receiving ACK).

In the picture you see the shorter line at address 9D50. Starting from the next line, when writing the bytes and reading them back afterwards, it has all 0xFF in it.

Did we miss something, what are we doing wrong or is this a fault in the boot loader?

Cheers

[TDK]

Odd that you're still getting ACKs if the commands are not working. But still could be a software bug.

> with our own flashing tool

Does it flash correctly with STM32CubeProgrammer?

[Tesla DeLorean]

The file looks legal, but not going to process a bitmap.

So either a failure in you parsing it, or some dependency on your side where it can't write 32-bit words. Are you writing 64-bit words currently? Need to better handle size/alignment corner cases better?

You could always normalize the .HEX file.

[Pavel A.]

Maybe the bootloader thinks that a short line always is the last line (indeed, why else can it be short?)

-- pa

[FS.1]

Hi,

ah, the "it can't write 32-bit words" gave me a hint. The problem is, it's not our code and it's quite hard to read. But now I found the part where the bytes are written and there it looks fishy. We are writing 8byte-wise. And there is some code to fill the remaining bytes if there is not 8 bytes to write. ... The code in question is quite convoluted so I need to discuss that with another colleague tomorrow.

Yes, our plan B is to normalize the HEX file but I wanted to understand the problem first.

Thanks for your answers so far.

[FS.1]

Hi,

we ended up normalizing the hex file to have all lines the same length and now it works.

Thanks