Is this an erroneous Intel Hex file? - Page 1
Forum section: electronics / general

author: HwAoRrDk
author_rank: Super Contributor
timestamp: March 03, 2020, 05:16:15 pm
content: I think I am encountering a bug with thestm8flashutility that is writing erroneous Intel Hex format files when reading back the flash memory of a device with more than 32KB. I thought I would double-check with the forum here before I go and make a fool of myself with a bogus bug report.I use the following command to read out the flash memory of the STM8S208RB (128KB flash) on my Nucleo dev board:Code:>stm8flash.exe -c stlinkv21 -p STM8S208RB -s 0x8000 -r "flash-write-test.hex"Determine FLASH arealibusb: info  could not access configuration descriptor (dummy) for '\\.\USB#VID_0424&PID_2514#6&182A12DA&0&5':  A device attached to the system is not functioning.Due to its file extension (or lack thereof), "flash-write-test.hex" is considered as INTEL HEX format!Reading 131072 bytes at 0x8000... OKBytes received: 131072(Ignore the libusb errors. I don't know why it does that; everything works fine otherwise.)When I try to import the resultant .hex file into my hex editor, it only gives an error telling me it has an invalid line with "incorrect amount of data". The region of the file containing the line it barfs on is:Code::20FFA000000000000000000000000000000000000000000000000000000000000000000041:20FFC000000000000000000000000000000000000000000000000000000000000000000021:20FFE000000000000000000000000000000000000000000000000000000000000000000001:020000040001F9:2010000000000000000000000000000000000000000000000000000000000000000000000E0 <-- error here:2010020000000000000000000000000000000000000000000000000000000000000000000C0:2010040000000000000000000000000000000000000000000000000000000000000000000A0:201006000000000000000000000000000000000000000000000000000000000000000000080Now, the obvious thing wrong here is that there appears to be a spurious extra character after the final checksum field, which is what I think my hex editor is complaining about. If I delete it, it complains about an incorrect checksum. However, I think that the last two characters of these records may in fact be the correct checksum, and the error is earlier in the record, in the address field - it just doesn't seem right to me.If I look up the details of Intel Hex format onWikipedia, it tells me the shorter line in the middle is an 'Extended Linear Address' record. Because the record format only allows for 16-bit (4 hex digit) addresses, if you're dealing with an address space greater than 16 bits (24 in my case), you have an additional record type to extended addresses, which forms the upper 16 bits of the address of all subsequent data records.Taking the sample above, there is an extended address record giving upper address bits of 0x0001. But then the following record has an address of 0x1000, making a combined 32-bit address of 0x00011000?Shouldn't it restart at 0x0000?There is another address extension further in the file:Code::201FFC000000000000000000000000000000000000000000000000000000000000000000021:201FFE000000000000000000000000000000000000000000000000000000000000000000001:020000040002F8:2020000000000000000000000000000000000000000000000000000000000000000000000E0:2020020000000000000000000000000000000000000000000000000000000000000000000C0I can see a pattern here: the stm8flash utility seems to be incorrectly adding the last nibble of the address extension as a prefix to all following addresses.Are my conclusions correct?

author: TerminalJack505
author_rank: Super Contributor
timestamp: March 03, 2020, 05:49:37 pm
content: I agree with your conclusion and this seems like an obvious bug to me. The address field should only ever be 4 hex digits but it seems to be 5 digits for addresses >= 0x10000 in your example.

author: techman-001
author_rank: Frequent Contributor
timestamp: March 03, 2020, 06:18:55 pm
content: Quote from: HwAoRrDk on March 03, 2020, 05:16:15 pmYour conclusions look correct to me. This is one of the good things about Ihex, it will tell you if something is wrong and what it is. So it looks safe to file a bug reportThis is a Ihex extended 4 format because Ihex can only handle blocks of 64k so there is a extended address byte after every 64k blockCode::20FFE000000000000000000000000000000000000000000000000000000000000000000001:020000040001F9:2010000000000000000000000000000000000000000000000000000000000000000000000E0 <-- error hereCode:020000040001F9 is the 64k extended address byteThis is one of my hex files at the 64kb stage, and as you say, it should and does restart at zero after the extended byte.Code::10FFF00040000355534247F8046D45F60046C4F2ED:020000040001F9:1000000000067047240001004000085553425F4538

author: cv007
author_rank: Frequent Contributor
timestamp: March 04, 2020, 01:51:59 pm
content: https://github.com/vdudouyt/stm8flash/blob/master/ihex.cline 133-fprintf(pFile, ":%02X%04X00",chunk_len,chunk_start);should be-> fprintf(pFile, ":%02X%04X00",chunk_len,chunk_start&0xffff);https://godbolt.org/z/TkLfXEa printf mistake, %04X is aminimumwidth of 4 with '0' paddingFix it yourself since you have the code.

author: janoc
author_rank: Super Contributor
timestamp: March 04, 2020, 04:46:08 pm
content: Quote from: cv007 on March 04, 2020, 01:51:59 pmAnd submit the fix to the author as a pull request so that someone else doesn't need to do all this troubleshooting all over again!

author: HwAoRrDk
author_rank: Super Contributor
timestamp: March 04, 2020, 06:41:24 pm
content: I already opened a new issue on GitHub for the bug yesterday, suggesting exactly that fix.I would fix it myself, but I don't have the appropriate build environment. I think it needs MinGW on Windows, and I can't be bothered to set all that up. And hardly worth a pull request just for one line.The Srecord output is correct, so in the meantime I'll just use that.

author: techman-001
author_rank: Frequent Contributor
timestamp: March 04, 2020, 09:53:07 pm
content: Quote from: HwAoRrDk on March 04, 2020, 06:41:24 pmIn that case you should change your ID to "ElAiSfYe"

author: HwAoRrDk
author_rank: Super Contributor
timestamp: March 05, 2020, 01:27:27 pm
content: I found the energy to attempt to build stm8flash myself in order to test the fix. Sheesh, what a palaver...Downloaded the MinGW-w64 installer and ran it. It's a web installer that does further downloads itself. I chose the x86_64 version; it failed to download that, and just exited after error-ing. Sigh. Try again, but leave it with the i686 default choice, which it successfully manages to download and install.Went to clone the stm8flash repository on GitHub. The 'Open in Desktop' link didn't work, just redirected me to the GitHub Desktop download page. Guess my already installed copy is too old, so I download the new version, install it and try again. Same result. Okay, copy the URL and manually clone it in the Desktop client myself. (In retrospect, how the hell is that 'Open' link even supposed to work? Communicating somehow between your browser and the native Desktop app. A browser extension needed?)Made the source code fix. Let's build this thing! Fire up a MinGW console, navigate to the stm8flash folder, type "make all". Command not found?Oh wait, the make utility MinGW bundles is for some bizarre reason called 'mingw32-make.exe', because why not have it different to all the other binaries?The build process gives errors as it can't execute 'uname' in order to find out what plaform-specific options to use. Okay, override that with a command-line option. Nope, still errors trying to execute 'CC'. Huh? But the makefile's Windows conditional branch sets CC to be 'gcc'. Sigh, I'll just override that manually as well. And now I get an include error from the compiler telling me it can't find libusb headers. I find and download the header/dll package for libusb, but I have no idea where to put the headers so it can find them. And then I notice that the makefile for some reason isn't even including the "-lusb-1.0" option in the generated GCC command line anyway.F@#% this.At this point I gave up.Later I notice while browsing other issue tickets on the GitHub repo, that the Windows build environment is assumed to be MingGWon Cygwin. Gee, it would have been nice if that was noted in the comment in the head of the makefile. FFS.

author: techman-001
author_rank: Frequent Contributor
timestamp: March 05, 2020, 08:53:51 pm
content: Quote from: HwAoRrDk on March 05, 2020, 01:27:27 pmMicrosoft Windows ... where would you like to waste hours today ?It took me 3 minutes with FreeBSD including downloading the release zipfile, applying Janoc's fix and making the project.Code:tp@gronk:~/downloads/stm8flash-master% gmakecc -g -O0 --std=gnu99 --pedantic -Wall `pkg-config --cflags libusb-1.0` -c -o stlink.o stlink.cstlink.c:62:6: warning: unused variable 'recv' [-Wunused-variable]int recv = stlink_read(pgm, buf, count);^stlink.c:484:7: warning: unused variable 'r' [-Wunused-variable]int r = libusb_bulk_transfer(pgm->dev_handle,^2 warnings generated.cc -g -O0 --std=gnu99 --pedantic -Wall `pkg-config --cflags libusb-1.0` -c -o stlinkv2.o stlinkv2.ccc -g -O0 --std=gnu99 --pedantic -Wall `pkg-config --cflags libusb-1.0` -c -o espstlink.o espstlink.ccc -g -O0 --std=gnu99 --pedantic -Wall `pkg-config --cflags libusb-1.0` -c -o main.o main.cmain.c:424:10: warning: enumeration value 'UNKNOWN' not handled in switch [-Wswitch]switch(memtype) {^1 warning generated.cc -g -O0 --std=gnu99 --pedantic -Wall `pkg-config --cflags libusb-1.0` -c -o byte_utils.o byte_utils.ccc -g -O0 --std=gnu99 --pedantic -Wall `pkg-config --cflags libusb-1.0` -c -o ihex.o ihex.ccc -g -O0 --std=gnu99 --pedantic -Wall `pkg-config --cflags libusb-1.0` -c -o srec.o srec.ccc -g -O0 --std=gnu99 --pedantic -Wall `pkg-config --cflags libusb-1.0` -c -o stm8.o stm8.ccc -g -O0 --std=gnu99 --pedantic -Wall `pkg-config --cflags libusb-1.0` -c -o libespstlink.o libespstlink.ccc -g -O0 --std=gnu99 --pedantic -Wall `pkg-config --cflags libusb-1.0` stlink.o stlinkv2.o espstlink.o main.o byte_utils.o ihex.o srec.o stm8.o libespstlink.o `pkg-config --libs libusb-1.0` -o stm8flash-rwxr-xr-x 1 tp tp 113429 6 Mar 07:41 stm8flashSadly no STM8's to try it on here.