PIC16F877 Branching Question.

[RT]

Hi all. I have a bug in my C program that has me stumped. For some reason, as soon as my main function achieves a certain size, it causes my program to branch to a specific location in a different function. This function is then executed repeatedly from about 1/2 way through to the end of the function until the processor sometimes seems to freeze or until I hit the reset button on the ICD Board. If I comment some functions out of the main loop, my program seems to work fine. At first, I thought it was a problem with the ROM paging and ISRs, but they seem to be working fine. Seems like the PC is getting set to the wrong value somehow or maybe I'm getting memory overwrite and a flag is being set accidentally. I did use *=16 to free up all RAM too even though the .lst file says I'm only using 125 bytes and 5 Stack spots from the main level. Also I've tried #separate with all my functions except ISRs. Any help would be greatly appreciated. Thanks in advanced.
___________________________
This message was ported from CCS's old forum
Original Post ID: 1105

[PCM programmer]

:=Hi all. I have a bug in my C program that has me stumped. For some reason, as soon as my main function achieves a certain size, it causes my program to branch to a specific location in a different function.

Also I've tried #separate with all my functions except ISRs.

The lst file says I'm only using... 5 Stack spots from the main level.
-------------------------------------------------------
What does the .LST file report as the "worst case" stack usage ?
That's the important one. It must not be greater than 8.

When you use the #separate directive, the compiler will not give
a warning if the stack usage is greater than 8. You have to
check the .LST file yourself, after each compilation.
---------------

Another thing to check is the Ram usage, which is given at
the end of the .LST file. See if any local variables that are
used by your ISR functions have been re-used by the compiler.
They are not supposed to be re-used, but there was a bug in
PCM vs. 2.7xx, where they sometimes were re-used. This bug
may still exist in vs. 3.xxx. If you find that this is happening, then try declaring ISR local variables as static. Then check the .LST file to see if that fixed the problem.
___________________________
This message was ported from CCS's old forum
Original Post ID: 1113

[RT]

:=What does the .LST file report as the "worst case" stack usage ?
:=That's the important one. It must not be greater than 8.
------------------------------------------------------------
I have checked the maximum stack usage and that number is 5. So I don't believe I'm having a problem with trying to use too much stack space.

:=Another thing to check is the Ram usage, which is given at
:=the end of the .LST file. See if any local variables that are
:=used by your ISR functions have been re-used by the compiler.
:=They are not supposed to be re-used, but there was a bug in
:=PCM vs. 2.7xx, where they sometimes were re-used. This bug
:=may still exist in vs. 3.xxx. If you find that this is :=happening, then try declaring ISR local variables as static. :=Then check the .LST file to see if that fixed the problem.
---------------------------------------------------------------
Is all of the assembly code shown in the .lst file strictly variable allocations? I am using mostly global variables and have no local variables within my main function. I have 3 ISR functions, RCV, TXMT, and TIMER2 and combined they only use one local variable and that is a short used for a flag within the RCV ISR. My .lst file says that my RAM usage is 125 bytes worst case. This should mean that I have plenty of RAM to not overwrite any locations. Correct?

Also, when using #define, is this basically the same thing as using const? I understand that #define is a preprocessor directive compared to a regular constant declaration, but I don't understand the difference between how #define values and const values are stored. I commented some of them out that were unnecessary and it didn't seem to free up any RAM in my .lst file.

Maybe I will try making all of my variables global in scope, and see if this helps at all. If I do that, all of my RAM will always be allocated in the same way and no values should ever be overwritten. Correct? I understand that this will use much more RAM, but even after doing this, I should have enough.

Thanks.
___________________________
This message was ported from CCS's old forum
Original Post ID: 1121

[PCM programmer]

:=I have checked the maximum stack usage and that number is 5. So I don't believe I'm having a problem with trying to use too much stack space.

So your .LST file probably reports something like this ?

Stack: 8 worst case (5 in main + 3 for interrupts)

I mentioned it, because you said you had "5 from the main level". But since you're using 3 interrupts, 3 more
stack levels will be used there.
If you call any functions from inside an ISR, that will
add additional stack levels to the "for interrupts" value.
Make sure that the sum of the "main" and "for interrupts"
values is not greater than 8.

:=--------------------------------------------------------------
:=Is all of the assembly code shown in the .lst file strictly variable allocations?

I use PCM with MPLAB. It seems that with version 3 of the
compiler, it does not automatically put a symbol table at
the end of the .LST file. To make it do that, I had to
go to the Project/Edit Project menu in MPLAB. Then click
on the .hex file (node), and then on the Node Properties button.
This brings up the CCS options window. Then where it says
"Additional Command Line Options", enter +LS. Exit from that,
and tell MPLAB to "Rebuild All", to recompile the project.
Then look at the end of the .LST file to see the symbol table.

Or, as an alternative, you can look at the .SYM file, which
also contains the symbols.


:= I am using mostly global variables and have no local variables within my main function. I have 3 ISR functions, RCV, TXMT, and TIMER2 and combined they only use one local variable and that is a short used for a flag within the RCV ISR. My .lst file says that my RAM usage is 125 bytes worst case. This should mean that I have plenty of RAM to not overwrite any locations. Correct?

I was referring to a bug described in this article.
<a href="http://www.pic-c.com/forum/old/messages/2089.html" TARGET="_blank">http://www.pic-c.com/forum/old/messages/2089.html</a>


:=Also, when using #define, is this basically the same thing as using const? I understand that #define is a preprocessor directive compared to a regular constant declaration, but I don't understand the difference between how #define values and const values are stored. I commented some of them out that were unnecessary and it didn't seem to free up any RAM in my .lst file.

That's because const values are stored in ROM.
See the article in the back of the Version 3 manual,
titled "How can a constant data table be placed in ROM ?".

:=
:=Maybe I will try making all of my variables global in scope, and see if this helps at all. If I do that, all of my RAM will always be allocated in the same way and no values should ever be overwritten. Correct?

You can check this by looking at the symbol table in your
.LST file, after adding the +LS option, as described above.
___________________________
This message was ported from CCS's old forum
Original Post ID: 1131

[RT]

OK, i checked the stack usage and it said 4 levels worst case. 3 in main and 1 for interrupts. This memory usage is:

ROM used: 2118 (26\%)
Largest free fragment is 2048
RAM used: 56 (15\%) at main() level
167 (46\%) worst case
Stack: 4 worst case (3 in main + 1 for interrupts)

I have also tried commenting out code and as long as my program stays on the first page of program memory, it seems to work perfectly. Then I add a some more code and cause it to go onto the second page of memory and it won't operate correctly. Basically the uC is supposed to receive a command via UART, which is to be executed and retransmitted, but at the same time, the TIMER2 interrupt is updating counters every second and keeping track of a 10 sec timer. It seems to receive & retransmit the command the first time, but then the second time, it receives it, but won't retransmit it.

Is there some kind of trick that needs to be done with the paging that I am missing? Also, does it matter how much program memory is free between the end of the stuff that will fit into page 0 and the beginning on page 1?

I have also checked my RAM usage and it doesn't seem like I am getting any memory overwrite.

Hopefully this is a somewhat clear description of what is occurring. I would paste code, but it is too long and there is not a portion that can be isolated that is really causing the problem. Thank you for any help anyone can offer.
___________________________
This message was ported from CCS's old forum
Original Post ID: 1238