Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

Hex file size depending on programmer software for PICkit 3

I programmed a PIC18F2550 on "PICkit 3" using an older software called "US-Burn" (see screenshot) and "PICkitminus" respectively.
Please find attached the source file and the two hex files. PICkit minus produces a far larger hex file. Disabling eememory reduces the file size only slightly. - It's not a big concern to me, just wondering.
 

Attachments

  • US-Burn.png
    US-Burn.png
    78.4 KB · Views: 12
  • V_dBm_Meter v4.bas
    3.4 KB · Views: 8
  • V_dBm_Meter v4.hex
    10.4 KB · Views: 8
  • V_dBm_Meter v4_PKminus_eeprom.hex
    90.9 KB · Views: 8
Is the chip erased before download? Pickit software itself does not generate code (hex files), just send what is in the hex file that was created by the compiler. However, if the Pickit thinks the chip needs erasing, it will insert (?) the FF code for the rest of the programmable space to clear old code.
It might be an option or check box somewhere in the programmer itself, not sure.
What I see are identical "code" in both files, and "FF" added for areas of the PIC that do not have code for it in the Pickit minus file.
If this is a reading back of the PIC, again it may be an option or the Pickit minus simply reads the entire chip because it cannot know where the code ends and blank space begins.
Start by looking at the hex file produced by the compiler only. It will be the smaller size. Then look at options for programming the chip itself and whether it is pre-erased.
 
I don't quite understand the question: "Is the chip erased before download?"
Dowwnload what? Do you mean "Write"?
I always "Erase" and "Blank Check" the chip before I "Write" to it.
The large hex file is a "Read"-back of the compact hex file created with the compiler.
I am attaching a screenshot of the file compare result with the file explorere "Total Commander v9.51".
Beginning in line 235 all the way down to end of file there is a huge amount of unnecessary code that blows up the file size. - As I said before, I can live with that.
 

Attachments

  • Hex file compare result screenshot.png
    Hex file compare result screenshot.png
    122.6 KB · Views: 1
Ok, it is the read back of the chip that created the larger hex file. Since the programmer/reader does not know where the code ends (it cannot interpret the bytes), it will simply read the entire PIC chip program space. Any PIC you read, the reading program will always read the entire chip unless there is an option to read only a portion.
Also there is in Pickitminus an option under "Tools" that skips blank sections. Not sure if that will help or not...
But bottom line, if reading a PIC chip (readback), it will usually read the entire chip, including the blank areas.
 
Thank you for the explanations. - I want to remeber in the future.
As an addendum, please look at the screenshot take from the end of file.
 

Attachments

  • Hex file differences only.png
    Hex file differences only.png
    114.1 KB · Views: 0

Latest threads

New Articles From Microcontroller Tips

Back
Top