# 8051 with Keil-C filesize issue using a Megawin processor

0 down vote favorite

I've written a program using Keil C for a MegaWin 8051 MPC82G516A. When I check the file size of the Intel generated hex file it has a size of 8kb (I see the code in the binary code window), but when I go to program the device using Megawin's tool it increases the code size to around 29kb!? Can anyone provide the reason for why it might be doing this?

Also, something else that is strange is the fact that it seems to be writing the code at the top of the processor memory and not at the start. There are like 4 bytes at the start of the code, but the complete rest of it is in the end of the memory.

Please help

Cameron.

• Where are you reading these 29kb? Intel hex format is basically a text file containing the binary data as ascii 0s and 1 characters, so the file itself will be significantly larger than the resulting binary. So perhaps this is your confusion? What is the file size in the windows explorer? Apr 24 '15 at 15:47
• @EugeneSh. - The hex file represents the binary data as two hex digits per byte, not ASCII 0's and 1's, so should be somewhat more than twice the size of the binary data it represents. Apr 24 '15 at 15:53
• @PeterBennett Right. Trusted my memory... But it is still Ascii representation, including addresses and separator. Apr 24 '15 at 15:54
• The file size says 8kb in internet explorer, when I place it in the megawin programmer and count the bytes it comes to 29,000 (or there abouts) Apr 24 '15 at 15:55
• Can you show the tool's output? Apr 24 '15 at 16:03

## 1 Answer

A hex file can skip 'don't care' locations by restarting at a new address (on each line, in general), so the hex file size might be considerably smaller than the binary bytes if there's a bit of content at the bottom of the address space and more content at the top. It doesn't mean that the files are not effectively identical. The line length also can vary between hex files and still represent the exact same data (since there is overhead per line, longer lines will give you a smaller file).

As to why Keil would choose to allocate program memory (or constants etc.) starting at the bottom or the top, bottom, or middle of the memory in the emitted code, I don't see why you'd care.. that's why you're using a high level language in the first place. So long as the compiler knows the correct memory range for the target, all should be well.

• Thank you for your answer. I do however have another question in reference to where the compiler stores the data. I have to save a large amount of data around 15kb in the flash. This is to store information that the application will write to during program execution. Is there a setting in Keil where I can specify what range it uses? Apr 24 '15 at 16:42
• AFAIR, you can reserve memory for your own purposes in a couple of ways- in the compiler or in the linker. Something like $_at_$ in the first case, and Reserve: in the second. Should be in your documentation. Apr 24 '15 at 17:38