View previous topic :: View next topic |
Author |
Message |
Bill Boucher
Joined: 04 Feb 2005 Posts: 34 Location: Chatham,ON,CA
|
v3 PICC puts my vars at x70-7F and ISR's overwrite them!!! |
Posted: Mon Jul 16, 2007 4:58 pm |
|
|
I am running a 16F688, programmed in v3 PICC.
The compiler is assigning some of my variables in the common ram area between x70 to x7F. When an ISR is triggered, the compiler code at the interrupt vector 0004 has to save context (saves W, PCLATH, FSR, and STATUS). When it does this, it writes W to x7F first, and others at sequencially lower locations. The result is that my variables, also located at 7F, 7D, and so forth or overwritten by the ISR contect saving code.
How do I tell the compiler to not put my variables between x70 and x7F ??? Shouldn't the compiler be smart enough to avoid this? It usually is. Is this a problem specific to the 16F688? Maybe a device header file issue?
Please help! |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Mon Jul 16, 2007 5:59 pm |
|
|
What's your exact compiler version ? You can find it at the top of the
.LST file, which will be in your project directory. It's a 4-digit number
in this format: 3.xxx (Don't post any numbers that come after it). |
|
|
Bill Boucher
Joined: 04 Feb 2005 Posts: 34 Location: Chatham,ON,CA
|
|
Posted: Mon Jul 16, 2007 9:06 pm |
|
|
PCM programmer wrote: | What's your exact compiler version ? You can find it at the top of the
.LST file, which will be in your project directory. It's a 4-digit number
in this format: 3.xxx (Don't post any numbers that come after it). |
The compiler version is 3.212 |
|
|
Bill Boucher
Joined: 04 Feb 2005 Posts: 34 Location: Chatham,ON,CA
|
|
Posted: Tue Jul 17, 2007 10:08 am |
|
|
Problem solved with easy workaround. I added the following line...
#reserve 0x70:0x7F
soon after the #device directive.
This prevented the compiler from sticking my variables into the common RAM area and the compiler still used this area for interrupt context save & restore. Viewing the "file registers" and "disassembly listing" windows confirmed this. My program is running perfectly now. |
|
|
|