Hi! Last time the title was mistakenly written as "and". My query is: I have read the code from AT89C51RD2 and dumped it into a file. This code worked well when burnt in other AT89C51RD2 controllers. Later i got its source code. Now i am generating the hex file. This hex file is different from one i copied from the controller. The generated file is in Intel Hex Format (i.e. starts with 0x3A) whereas the coped hex file starts with 0x02. What is the difference between two hex files?
But this file "the one which starts with 0x02" works well when loaded into the controller. The character strings used in source code can be seen easily in this file when viewed in UltraEdit and also on two Row LCD. If this is not an Intel hex file, then why this works when loaded into the controller?
The file which starts with 0x02 is a BINARY file. That means that every byte placed in the controller memory is represented by one byte in the file.
Because of this, you will be able to read the LCD text strincs, since every one-byte character printed on the display is a one-byte character in the input fle.
The Intel-hex file stores two characters 00 .. 99, A0 .. FF (in total 255 combinations) for every byte stored of the controller memory. It is also storing address and checksum information.
Because of this, the Intel hex file is more than twice as large than a binary file. And any text strings will not be readable. If you have a LCD string with the character A, the ASCII value of the 'A' character (65) will be stored as the two-character hexadecimal value 41 in the Intel-hex file.
An Intel Hex file must be transmitted to the controller by using a transfer program that specifically processes an Intel Hex file. A binary file must be transmitted to the controller using a transfer program that specifically processes a binary file. If the transfer program only supports one format, or is configured to transfer the wrong format, then the input file (binary or Intel Hex) may be completely correct but the controller will NOT be able to run.
Thanks for the reply! This really helped me to classify two different formats and it also opened different options for me to proceed further. Using uV3 i can generate only Intel Hex File. How can i convert it to Binary file? Can you please elaborate this sentence:- "A binary file must be transmitted to the controller using a transfer program that specifically processes a binary file." Is this something about the programmer which loads Hex file to the controller?
The danger of not proof reading.
"in total 255 combinations". Should of course be "in total 256 combinations". Was originally "all values between 0 and 255", before I made a lousy edit.
It is important that the programming software supports a specific file format and that it sends the data in the correct format to the controller.
If transmitting data to a boot loader, the boot loader may make use of Intel hex or similar, and process the individual checksum information.
If transmitting directly into the flash (possibly through a tiny "programming algorithm" help program running from the processor RAM, you normally transmit the data in raw binary.
The software you are using to transmit the data should have one or more supported file formats that it can open. For each of the supported file formats, it will either transmit the data transparently to the controller, or convert the data to the format expected by the controller.
If the transfer program can only make use of binary files, and you force it to load an Intel hex file, it will send garbage to the controller. Same thing if the transfer program only supports Intel hex, and you force it to open a binary file.
That is one reason why you can have multiple valid input files, but fail to program using some input file formats. Another thing is that a binary file does not contain any address information. The transfer program must either know exactly where to put the binary data, or it must have input fields where you can enter the target address. An Intel hex file already contains the load addresses (each line of text in the file has a record type, and the record type contains a target address, actual data or a marker that the end of the file has been reached) so it can contan multiple blocks of data, and the transfer program - or the receiving processor. Besides the raw binary file format, there are a number of binary formats that may contain extra meta-data such as debug information, load addresses etc. One such format is the elf format. Inside the elf file you will find raw binary data intended for the processor, but the information has been encapsuled into a file with additional info to make sure that the data is sent to the correct address, or to help in debugging.
I normally don't use the C51 tools, so you have to ask someone else what tools or linker options Keil supports for controlling generated file format.
http://www.keil.com/download/list/utility.htm