A Question about Programming the PIC18F452 re: .hex and .lst files

[SuzyC]

I am trying to get my PIC452 custom programmer to work, it does not, please help me understand what I am doing wrong.

My old Hi-Tech 9.80 compiler I am using compiles my C-source and generates a .hex file to load into the '452 without any errors. My hardware then uses this file as the programming data for my custom hardware that is supposed to program a '452.
The result of my hardware efforts to program the '452 results in chaotic unexpected results. Something is very wrong.

My hardware seems to program the '452 chip's CONFIG area correctly. My program and hardware verifies the programmed program code without error.
But something is obviously very wrong!


My compiler (Hi-Tech 9.80 for PIC 14 etc.) generate both an .hex file and a .lst (ASM) file.
 
The .hex file shows an initial boot jump which then again jumps to a location that is part of float to integer routine labeled PL2,(that is according to the .lst file). 

My first question: Does the .lst file usually agree with the .hex file generated, or is the .hex file the result of optimizations and other compiler processing?

[Bruce Abbott]

The hex code in the listing file(s) should match the code in the hex file.  'chaotic unexpected results' suggests either a bug in the program or hardware issues (eg. 'floating' inputs, bad power supply).

To test your setup, try running a simple program that just toggles an output pin or blinks an LED (example). If this works then your code is suspect. If not then either the PIC is not being properly programmed or there is a hardware fault.

You could also try running the hex code on a simulator.  MPLAB 8.92  can simulate a hex file without having to create a project for it. Just set the debugger tool to MPLAB SIM and the device to PIC18F452, view program memory and import the hex file. You can then single step through the code.

[SuzyC]

Thanks Bruce, I'm going to create a simple blinky routine and see if the MCU result is stable.

I can easily see that the boot jump is to a nearby line that jumps to a first address that then just jumps to another address that is a part of the standard routine for Float to Integer conversion (I am matching the reset boot jump addresses in the .hex file with the AS< code address in the .lst file), and this shows clearly the second jump address is not to the start of main().

I have used this compiler before with 18F45K22 chips to create a few simple projects without any problem.

My problems began when I tried to code a  programmer routine  for the 18F452.

If it is true that the output of the compiler .hex code is  an optimized version of the ASM, or is otherwise changed by the compiler, and in this case  the .lst (ASM) file would not match the .hex file.

But I donno!

I could easily post small snippets of the .hex file and the .lst file to clarify. Would this help?

What I see when I just run this code in main() with the start:

I have an TMR0 ISR that counts IRQ's to increment a var called Sec++; //correctly each second
This bad result was with the original larger source code.

void main()
{ .....
   .....
start:
 if(Sec & 1)
  {LATB7=1; //connects to a LED to a resistor to VSS.
  }
else
 { LATB7=0;
 }
goto start;

What happens is the the light blinks on for a short period and then stays off. What's worse is that by simply swapping the positions of small adjacent C-code would create different, but chaotic results. I have all IRQ's in check, because I can see the Interrupt routine repeats at the expected 100uSec.

Here's the surprise: Any code in the interrupt server routine runs correctly, code in main() is chaotic.
 
It looks to me like a continuous stack overflow problem.

I am now going to try to create a very much minimalist version of the same code to see results I get when I pop the programmed DIP chip into a breadboard..