When I looked up the stlink utility , I couldnt see 1,2 and 3 shown in the figure?What are these can sb tell me about it?
The .HEX file is in an Intel format that defines record structure.
1) Checksum field for the record
2) is a segment address, other records use 16-bit address, so only describe 64KB regions.
3) Is the record size, address, and type
Intel HEX - Wikipedia
I also found this line at the first line => :020000040800F2
and this two at the last line => :040000050800018965 :00000001FF
I didnt found these in intel hex
Did you read the Wiki? The .HEX is an ASCII encapsulation format, not all the record content gets into the memory of the device.
Record Type 04 at the front is describing what memory window the following record fall into, ie 0x08000000 being the base of FLASH memory
Record Type 01 at the end is a terminal record
Record Type 05 is the execution/entry address, nominal points at Reset_Handler
Thanks for your help but I expected to get the value of loaded into Flash in Record Type 05 according to Wiki.I dont get it?The four data byte is => 08000189 What is this?Also How can I record the reset handler in Flash Memory?How will the microcontroller understand that flash memory is reset handler?
It is meta data for the debugger or loader, the CPU uses the value in the vector table already described in the flash content portion.
The HEX file format was created by Intel in 1988 (http://microsym.com/editor/assets/intelhex.pdf ).
Don't confuse this file format with a file full of hexadecimal numbers. The HEX file format is intended for representing object code so that it can be placed correctly in a microcontroller's memory. Meanwhile, since disk space was really expensive, don't waste space by filling in unused memory locations. To do that a bunch of extra data is added.
There are addresses so that the code can be placed.
There are checksums so that the code can be verified to be correct.
There are checksums and record counts so that short files are detected before causing corrupted memory.
The file format was invented at a time where each record would be transferred, slowly, using a serial or parallel printer port, between a slow computer and the programming device. Each record should be checked using the checksum, and all records should be received and checksummed to make sure that the image is complete before actually writing the image into the PROM/EPROM/EEPROM/FLASH (since erasing could take 45 minutes). The programmer would then verify that the write was done properly by reading back the device and comparing it against the image without re-reading the image from the computer (since rereading the file would be slow and the device can't even request the image anyway).
If you don't think that the checksums and record counts, load addresses and terminators, are useful, you're on your own. A lot of these artifacts are historical, but they are there to help you.
>>The HEX file format was created by Intel in 1988
The 32-bit additions perhaps, the format is at least a decade older than that. The Motorola S19 format was from the 1970's, and Intel had their equivalent for the 804x and 805x parts. See Motorola EXORmacs and Intel ISIS
Intel HEX – Wikipedia The German version cites 1973
Which makes a lot more sense. I seem to remember using HEX files in '84 at my first embedded systems job.
Yes, because otherwise the both of us would have caused some hideous time paradox.
Or William Hartnell meets Christopher Eccleston in a dark alley, a hideous pair of docs.
Retrieving data ...