debuggingpic
I am having problems with the MPLAB X debugger (although the release build works fine). It behaves very weirdly with my PIC16LF1937-based PICKIT3. Specifically:
What could I be doing wrong? What things should I check?
I used an assembly template located here from Bill Howl on this website and wrapped your delay routine around it.
I payed particular attention to the port initialization routine example given on the microchip datasheet pg 124 Example 12-1 Initializing port A. The BANKSEL PORTA just before the delay routine and port toggling kicks off is crucial! Doesn't appear to have the problem your are experiencing with the program counter. Simulated for 806 seconds... And no issues. Sometimes it helps to clean the project code up by clicking project, clean.
Your second piece of code is causing stack overflow errors
CORE-E0001: Stack over flow error occurred from instruction at 0x000037
CORE-E0001: Stack over flow error occurred from instruction at 0x000037
CORE-E0001: Stack over flow error occurred from instruction at 0x000037
CORE-E0001: Stack over flow error occurred from instruction at 0x000038
This is because you are missing the return statement in the AUXHELLOWORLD block.
When your code starts it would cause an infinite never-ending loop of these two calls (initialise and auxhelloworld) each time adding to the stack and never getting popped back.
Eventually the stack will be overwhelmed and lose track of where it is supposed to return causing strange code behaviour and program counter to jump about.
START
CALL INITIALISE
CALL AUXHELLOWORLD
Try the template!
Really you should learn c code and download the microchip or Hitech c compiler. It will make your life much easier... You won't go back to assembly!
Furthermore you can also incorporate assembly in c code, if you really needed the specialised code.
It seems that you need a pull-down resistor on INT0,(you do not seem to mention you have one), my clue to needing a pull resistor is your problem number one, where your body affects the change of state. This problem arises because you have a high impedance input (INT0) and it is floating, there is no guarantee that your INT0 is low because it is left floating until you pressed the button and held high. Adding the pull down resistor will defualt your INT0 state to low, also remember that your probe looks like a cap with a resistor in parallel, so every time you probe your circuit you are basically placing a pull down resistor. The other issue I see is that your button is not debounce, adding a delay of a few millisecond will not debounce an input.
Best Answer
I question the stability of your release build if you cannot debug it at all.
Building for debugging adds some extra meat to your HEX file, meaning things aren't always in the same RAM and flash locations they are in a production build. This has (for me) sometimes shown some software bugs that I didn't see in production mode (case in point - I think I found a bug in the XC16 string library where sscanf is throwing address errors when dealing with chars, which only showed up after I started debugging and a char moved to a different RAM location)
If you're debugging and you have WDT enabled, disable it - the WDT doesn't play well with the debugger freezing time by stopping the micro.
Before you add breakpoints and other stuff, simply run the program as-is in debug mode - no single steps, just execute. The code should just 'work'.
For detailed help, you'll need to post a minimum code sample that works fine in production mode but hangs up when debugging. (This exercise may show you some buggy code that you didn't realize you had.)