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?
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.