Parse HEX File to HAL_FLASH_PROGRAM()

[Martini]

Hello everyone, I want to make bootloader, everything is done, but not working. 

1. I create two apps in STM32CubeIDE:

BOOTLOADER: 0x08000000

APPLICATION: 0x08020000

I did simple program and I jump from app to boot, and from boot to app (It's works fine).

2. I send (In next step using GSM) my hex lines using UART, and I receive it correct.

3.I get address, type, checksum from every lines and I parse only data bytes (I see in debug its working good).

4. I clear memory, and try to flash program   and just not working. 

When I parse hex file I skip the first line and two the last line (do not contain data). In every line I skip ":10100000" (length, address, type)

I don't know if I do this correctly.

Someone maybe know why the penultimate line have type 05, data like: 08023C25

What should I do? 

[Tesla DeLorean]

The format isn't particularly complex and is well documented. Perhaps decode in C on a PC. Check conversation to BIN file.

Check binary with your STM32 side loader.

[TDK]

https://en.wikipedia.org/wiki/Intel_HEX

[Martini]

I compare the .bin file and .hex, data is the same.

I debug my program i I correct write data to flash  (exmaple in screen). 

But its not working maybe I do something wrong. 

Maybe i should write data as little endian?  

My first data line is:
:10 0000 00 00000320010902086D08020873080208 B5

Its ok when I write for example: (look screen of debug)

0x08020000: data: 0x00000320

0x08020004: data 0x01090208

etc.

 

[TDK]

Data in memory needs to be in the same order as in the file. The system is little endian so data should appear reversed when interpreting it as a uint32_t.

[Martini]

Thanks for answer. You are best.

I want to understand correctly. 

If I have first line:

:10 0000 00 00000320010902086D08020873080208 B5

Data is: 00000320 01090208 6D080208 73080208

Should I write like this?

0x08020000, data: 0x00000320

0x08020004, data: 0x01090208

0x08020008, data: 0x6D080208

0x0802000C, data: 0x73080208

[TDK · Accepted solution]

If "data" is a uint32_t, it should be reversed compared to what is shown in the hex file.

0x08020000, data: 0x20030000

...

Isn't this easily verified? Try one way, if it's reversed in memory, then reverse it before writing.

[Martini]

You are the best TDK :) 

I wasn't sure, I had more problems, but your answer helped me - you have right.

Data in .hex file is Big Endian, and we have to change it to Little Endian.