View previous topic :: View next topic |
Author |
Message |
Ahmed
Joined: 07 Mar 2006 Posts: 19
|
functions return to different location. |
Posted: Sat Apr 22, 2006 4:28 pm |
|
|
I'm using PIC 16F877, my code starts getting large and I知 dividing it to number of files then included them in the main. The include files are calling functions from each other.
I知 getting weird results now and I couldn't get the problem but it seems that the functions return to different locations instead of the location it was called from.
Anyways, i'm not sure whether this explanation is enough or not; but if any body get any ideas please advice
Thanks |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Sat Apr 22, 2006 6:27 pm |
|
|
Quote: |
I知 getting weird results now and I couldn't get the problem but it seems
that the functions return to different locations instead of the location it was
called from. |
Look at the number of stack locations that are used by your program.
You can see this value near the top of the .LST file. (Look in your
project directory for his file).
For the 16-series PICs, the number of stack locations used should
be a maximum of 8. If you use more than that, you will get erratic
program operation, such as you have observed.
Here is an example of the stack usage report at the top of the .LST file:
Quote: |
ROM used: 98 words (1%)
Largest free fragment is 2048
RAM used: 14 (8%) at main() level
16 (9%) worst case
Stack: 3 worst case (1 in main + 2 for interrupts)
|
Normally the compiler checks this for you automatically, and will
prevent the number of stack locations from exceeding the maximum
number. But if you use the #separate directive anywhere in your
program, the compiler will not check the stack usage anymore.
You have to check it yourself by looking at the .LST file every time
the program is compiled. My advise is don't use #separate if you can avoid it. |
|
|
Ahmed
Joined: 07 Mar 2006 Posts: 19
|
|
Posted: Sat Apr 22, 2006 6:57 pm |
|
|
i wasn't able to find the .LST in the project directory. i got only .COD, .ERR and .HEX; i looked in Build options and list file was checked (ON). any idea of what is going on!
Thanks alot PCM |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Sat Apr 22, 2006 7:29 pm |
|
|
It should be there. Are you using the CCS compiler ? |
|
|
Ahmed
Joined: 07 Mar 2006 Posts: 19
|
|
Posted: Sat Apr 22, 2006 8:06 pm |
|
|
yes, i'm using ccs compiler. can i check the stack using any other way.
thanks |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Sun Apr 23, 2006 12:57 am |
|
|
Quote: | i wasn't able to find the .LST in the project directory |
To get the .LST file, you have to do a successful compilation.
If you get errors, the compiler won't make a .LST file.
If you can't find the .LST file, there isn't much more I can
do to help with your problem. |
|
|
Ahmed
Joined: 07 Mar 2006 Posts: 19
|
|
Posted: Sun Apr 23, 2006 7:24 am |
|
|
i follow your advice and try to remove some of the # files. the compiler start to get out the problems; finally i ended with "NOT enough RAM for all variables".
Due to limited time, I知 thinking of changing the PIC instead of editing all of the code.
I'm using PIC16F877A, after searching i found that same pin assignment and a bigger RAM size with the required features in the PIC18F442. Depending on my knowledge i think that when i change the PIC it should work.
If you know any constrains that will make this migration not possible please, advice so i try finding other solutions.
Thanks for cooperation. |
|
|
Mark
Joined: 07 Sep 2003 Posts: 2838 Location: Atlanta, GA
|
|
Posted: Sun Apr 23, 2006 8:17 am |
|
|
From this statement,
I知 getting weird results now and I couldn't get the problem but it seems that the functions return to different locations instead of the location it was called from.
Leads me to believe that the code compiled just fine and that you were able to run it so you should have a lst file.
The PIC18's require you to have the PCH compiler and not the PCM. If you have PCH or PCWH then you can use a PIC18. |
|
|
Ahmed
Joined: 07 Mar 2006 Posts: 19
|
|
Posted: Sun Apr 23, 2006 10:32 am |
|
|
ok, after i compiled the program using ccs direct instead of MPLAB then the .LST appears!!!
after i cancelled some of the #files and isearted them in the main then i had the following in Error:
Quote: | Error[71] biometrics_v1.c 567 : Out of ROM, A segment or the program is too large.
main
Seg 1000-17FF, 0630 left, need 0780
Seg 1800-1FFF, 0800 left, need 08B4
Seg 0000-0003, 0000 left, need 08B4
Seg 0004-07FF, 000F left, need 08B4
Seg 0800-0FFF, 0016 left, need 08B4
Seg 1000-17FF, 0630 left, need 08B4 |
i tried to close part of the program to compile it and check .LST file and it was as follow;
Quote: |
ROM used: 5212 (64%)
Largest free fragment is 2048
RAM used: 61 (35%) at main() level
175 (100%) worst case
Stack: 6 locations
|
Is the 100% critical. coz it still not working fine.
please, any explaintation of what is going on !!! |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Sun Apr 23, 2006 10:53 am |
|
|
Do you have one function that is very large ? If so, try to break it up
into two functions. This will allow the compiler to find a location in ROM
for the functions. It's easier for the compiler if you have smaller
functions. Example:
Code: | main()
{
func(); // One very large function
while(1);
} |
Code: | main()
{
// Two smaller functions
func_A();
func_B();
while(1);
} |
|
|
|
Ahmed
Joined: 07 Mar 2006 Posts: 19
|
|
Posted: Tue Apr 25, 2006 1:46 pm |
|
|
Quote: | if you use the #separate directive anywhere in your
program, the compiler will not check the stack usage anymore.
You have to check it yourself by looking at the .LST file every time
the program is compiled |
ok, my .LST file was as follow showing 7 locations only:
Quote: | ROM used: 5790 (71%)
Largest free fragment is 2048
RAM used: 69 (39%) at main() level
171 (98%) worst case
Stack: 7 locations |
Is this mean that the initial problem (function returns..) isn't related to the stack or still this calculated stack location were not accuratedue to the #seprate files. |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Tue Apr 25, 2006 1:55 pm |
|
|
If there are only 7 stack levels listed, then there should be no problem
with stack overflow.
Do you still have the problem with functions returning to incorrect
addresses ? If so, here are some possible reasons:
1. Did you enable global interrupts while inside an interrupt routine ?
2. Are you using #ASM code, and jumping to some location in your
program ?
3. Are you using any special functions, such as goto_address() ?
Other possible reasons:
1. If you accidently write to RAM locations past the end of an array,
you could destroy the value of some variables (such as loop counters)
and your program would have erratic operation. |
|
|
|