View previous topic :: View next topic |
Author |
Message |
dacenrie
Joined: 02 Mar 2006 Posts: 16
|
Compiler gets lost |
Posted: Mon Oct 08, 2007 11:52 am |
|
|
I'm using PIC16F737 and when I compile and run my program from debugger mode, the compiler gets lost and points to the middle of nowhere in program memory. I have no idea what causes this. Has anyone else experienced the same problem?
Would the problem be caused by (i'm just guessing) long nested if-else statements or multiple statements in a single switch statement case?
Please help. I've been experiencing this quite a bit. |
|
|
ckielstra
Joined: 18 Mar 2004 Posts: 3680 Location: The Netherlands
|
|
Posted: Mon Oct 08, 2007 4:06 pm |
|
|
What is your compiler version? It is a number like v3.249, v4.013 or v4.056. |
|
|
dacenrie
Joined: 02 Mar 2006 Posts: 16
|
|
Posted: Mon Oct 08, 2007 4:44 pm |
|
|
Version 3.227 |
|
|
ckielstra
Joined: 18 Mar 2004 Posts: 3680 Location: The Netherlands
|
|
Posted: Mon Oct 08, 2007 4:50 pm |
|
|
That's a reasonable stable version. I don't know about the PIC16 but I'm a happy user of v3.226 for the PIC18F458.
Which debugger are you using the MPLAB ICD2 or CCS unit?
Debugging environment is CCS or MPLAB?
How ROM, RAM and stack is your program using? Please note that debugging units like the ICD2 use small part of the ROM, RAM and / or stack space. See the ICD2 online help file for more detailed info. |
|
|
dacenrie
Joined: 02 Mar 2006 Posts: 16
|
|
Posted: Mon Oct 08, 2007 5:02 pm |
|
|
Yes, I'm using an ICD2 with an MPLAB IDE. I know for a fact that i'm not accessing any of the debugger's reserved memory space.
BTW, would adding a char and int16 value, then storing the result in an int16 variable be a problem perhaps? |
|
|
barryg
Joined: 04 Dec 2006 Posts: 41
|
|
Posted: Fri Oct 12, 2007 12:55 pm |
|
|
I have had this happen when some of the chip wasn't programmed (I had set the programming range manually). Also having the wrong (different memory size) chip selected. I don't recall being able to get the compiler to make code that goes off into space, except when doing something unconventional (e.g. using GOTO_ADDRESS and doing too many returns). Overflowing the stack (as did with the GOTO) might do this (but as I said the compiler generally won't let this happen). Make sure you've programmed the chip after setting MPLAB in debug mode. Failing all that, try to find which statement causes the program to go off into space. Then, open the Program Memory window and step through those instructions until you find the offending branch. If you have to go that far. At some point the light will go on...as it did for me. |
|
|
|