I work with a prototype microcontroller, so Flash-magic programs cannot be poured. The creator company sent a curved oblique prog to fill the firmware, so I wrote my own. As a result, I ran into a problem, I can not load the Hex file into the MC.
I made a .bin file using the algorithm “Extract the data field from each line of the Hex file and convert this data to the byte data type with offset (each works correctly, checked, checking with the online converter). I put all this data into the byte array.” This array is written in RAM MK, but there is no result.
Here is a screenshot of the .bin file opened in the HxD program: 
Who has experience in this business, can prompt? Preferably in the language of the family C. Thank you
- Do you need a program code when the question was to get me a piece of code that is responsible specifically for breaking the Hex file and throwing it into an array for later unloading? The error lies in the fact that it is not-MK after downloading, I just do not answer anything. Just no answer. Therefore, such a formulation. - George Tuzikov
- The format of the HEX file with the firmware is described, what is the question? - Vladimir Martyanov
- You probably have the wrong data converted to binary format. You got the text from the decimal numbers in the ascii-like encoding (seen on the right column in the picture). If it were a binary format, not a text format, the right column would consist of spaces and a meaningless (for a person) character set. - insolor
1 answer
The Intel Hexadecimal object file format contains hexadecimal code presented in text form. It contains not only the executable code, but also control data. The format description is here . There is a description in Russian here .
Alternatively, the hex file can be converted to bin using third-party programs, for example, hex2bin .
UPD. When you have a bin-file, there should be no questions. You just need to take from it byte by byte (or word by word, depending on the architecture and debugging protocol) and transfer it to the controller.
In the hex file, hexadecimal data is presented in text form. End of line characters here are part of the file format, but not part of the executable code. You need to read this file line by line, extract control information and executable code from it. For example, each line contains the number of bytes to be written, the offset, the type of the record, the executable code itself, the checksum byte. Extract the executable code from the string and write it to the controller's memory.
About the low byte forward. This refers to the order of bytes in a machine word. The size of a machine word depends on the architecture of your controller, but usually it is 32 bits (4 bytes). Most likely, you need to transfer bytes from the end within each word. For example, you have such an array of bytes:
12 aa 55 88 bb 77 ee 66 55 22 77 dd 6d 45 9a 32 It needs to be transmitted as follows:
88 55 aa 12 66 ee 77 bb dd 77 22 55 32 9a 45 6d At the same time, check the compiler settings: it can already generate a file with the order of bytes that your controller needs. More information about the byte order can be searched for requests Endianness, Big endian, Little endian.
ps Updated the link to the Russian description.
- And then just write a binary on MK? - George Tuzikov
- @GeorgeTuzikov, yes, exactly. - maestro
- And if it is Hex to write, then it is necessary to submit it with all the characters, including CR LF? And another such moment, in Dadashite, it is written that it is necessary to feed the array with the low byte first, so it turns out I need to start at the end of the file? - George Tuzikov
- @GeorgeTuzikov, updated the answer. - maestro
- Well, I took a field with data from each line, paired them into a byte form, and as a result I got a .bin file, but the MC still does not accept it. I opened this binary with the HxD program, it reads it calmly. I will attach a picture to the post - George Tuzikov