STM32 Xmodem Protocol Hex File Parsing

[mehmetdm]

Hi,
I am trying to update the firmware with an xmodem protocol over a uart with stm32. I convert the hex file created by CubeIDE into an Xmodem 1k package and send it. The bootloader I wrote in Stm32, receives this data and writes it to the necessary address. There is no problem on this side.

However, there is a difference between the program I sent and the program compiled and written by CubeIDE. This causes the program to not work properly.

There are some lines in the hex file that are not completed to 16 bytes, I add 0xFF to the end of them, package them and send them like that.
                                        .
                                        .

                                        .
:10026000B1240408B1240408B1240408B12404080A
:10027000B1240408B1240408B124040800000000DB
:10028000B1240408B1240408B124040800000000CB
:0802900000000000B124040885
:1002A00010B5054C237833B9044B13B10448AFF3B0
:1002B00000800123237010BD0C0200240000000008
:1002C00058D9040808B5034B1BB103490348AFF3E1
                                        .
                                        .

                                        .

                                        .

Here, I complete the 8-byte line to 16 and send it like that. This line is somewhere at the beginning of the hex file. This line matches no problem.

:10E2B00065776C69622F6C6962632F7374646C6933
:10E2C000622F6764746F612D6765746865782E636B
:04E2D000000000004A
:08E2D4000C20FF7F0100000097
:04E2DC00C50204086B
:04E2E000A10204088B
:10E2E400010000001E1A09162700000000000000AB
:10E2F400000000000000000000000000000000001A
:10E304000000000000000000000000000000000009

However, towards the end of the hex file, such a line comes again and again I complete the end with 0xFF and send it.But this place doesn't match.

In the photo I added below, there are flash memory views of the program I sent and the program sent by cube ide. Here it shows the mismatch.

How should I send these packages?

[Tesla DeLorean]

>>There are some lines in the hex file that are not completed to 16 bytes, I add 0xFF to the end of them, package them and send them like that.

That seems like an overly naive approach.

What's wrong with the short lines, they describe the length and address properly? They aren't all on 16-byte boundaries.

Send them as built, or normalized them properly. You might need to read more that one line to construct a complete line.

Or process them in a way that can tolerate word alignment, where the STM32 involved permits 32-bit writes.

Where it needs 64-bit, say, create a line that you fill as bytes/words arrive, and flush that to FLASH once a deeper address is sent.

Or send as a binary

[Pavel A.]

> What's wrong with the short lines, they describe the length and address properly? They aren't all on 16-byte boundaries.

That's exactly the problem. Writing to the flash requires certain alignment. The only way is to convert the hex to the final binary image with all holes filled, duplicates resolved etc. That can be converted back to a hex or whatever.

 

 

[Tesla DeLorean]

I'm not sure we've clearly established which STM32 is at play here.

The .HEX isn't assured to be linear, and can be sparse. I have furnished tools in the past capable of ELF2HEX conversion where I provided 64-bit (8-byte) alignment for the STM32L1, as I recall, when Atollic was outputting problematic files via objcopy.

Generally I would say use a ELF2BIN type tool, and then a BIN2HEX type tool to get a PC side file normalized.

I'd code stuff on the STM32 that were more flexible, and not be reliant on fixed line lengths, and consolidate a FLASH-LINE prior to pushing to the array. I've build STM32 code to digest HTTP/SDCard derived .HEX files, and you'll usually can't guarantee the methods/tools used to create up them.

Binaries are generally preferable as you can validate the image longitudinally rather than line-by-line. Add meta-data, sign, encrypt, etc.

[Karl Yamashita]

Sounds like a bootloader parsing and/or writing issue. Even if the Hex line indicates there are only 8 bytes, it's up to the design of the bootloader to write those bytes correctly even if it's not 16 bytes.

You indicate that the STM32 receives the data and writes to the necessary address with no problems. However, if you say the program does not work properly, then the bootloader did not write the data to flash correctly.

[mehmetdm]

Thanks for all the answers guys. I solved the problem by sending binary. 

But back to your hex questions. When I first loaded the program with xmodem, the program didn't work. Later, when I compared the flash memory dumps (The version I loaded vs the version I loaded from Cube IDE). I saw that the short lines weren't loaded correctly, I tried a few things to fix this (like adding 0xFF at the end of the short lines) but it still didn't work. The problem was that I couldn't figure out what logic was behind writing the short lines to memory, but I don't need it for now. I can update the program with binary files.

 

[Andrew Neil]

---

@mehmetdm wrote:

 I couldn't figure out what logic was behind writing the short lines to memory

---

If you want to make an Intel Hex processor you do, of course, need a thorough understanding of the complete "protocol"!

So a more complete version of

"it's best not to try to do Intel Hex decoding in the microcontroller"

would be

"it's best not to try to do Intel Hex decoding in the microcontroller unless you have a thorough understanding of the format, and are prepared to make a full & complete implementation"