I get trapped in DELAY code if it is INTERRUPTED by TIMER 2

[Gregg.Ariss]

I have a most perplexing problem.

I have a system that requires a real time clock. I wrote a program that used Timer 0 and it worked a treat. However, I have redesigned my system to use Timer 2 as a real-time clock, since I have a better use for Timer 0 and 1.

Now my system hangs.

The problem seems to lie in the DELAY assembly code added to the start of the absolute program listing and its' interaction with the interrupt dispatcher.

My program will run ok, as long as the delay_ms routine is NOT interrupted by my Timer 2 ISR.

As soon as the Timer 2 ISR is triggered (and exited, of course), I get trapped in DELAY.

I'm confident it is not a problem with my code in the ISR, since, for testing purposes, I have just added a NOP there.

If I DISABLE the timer 2 interrupt immediately before my delay_ms() line, and re-enable it immediately after the program works.

I think the problem lies with CCS' interrupt dispatcher and its' entry and clean-up code. I'm using version 2.683 of the compiler. Is there a known bug in this version?

Looking at the compiler generated code, I notice that the compiler adds three instructions to the end of my ISR - one to re-set the timer 2 flag (and the bit address is correct), 2 instructions to do something I don't understand with PCLATH. Does anyone know what those lines do?

Also, looking at the inline DELAY code at the head of my absolute listing, I notice that it comprises several nested loops that manipulate W and several SFR's. I could imagine that the interrupt dispatcher could corrupt W on exit, just before the program counter returns to the DELAY routine, but I can't see how. The first thing the interrupt dispatcher does is store W in SFR 0x7F (at least I think it is 0x7F if memory serves; forgive the pun). But on exit, CCS' dispatcher does something very strange, instead of restoring W from 0x7F, it uses SWAP to exchange nibbles at 7F, then does another SWAP, storing the result in W. That seems crazy to me, but I can't see how it would make any difference.

On the other hand, maybe the problem lies with the way CCS' interrupt dispatcher manipulates the program counter.

Is this a compiler bug? Because it certainly looks like one to me.

Searching the board I see some references to a mysterious "problem with 16F877.h in older versions of the compiler. What was this problem?

Thanks for any help you can offer.
___________________________
This message was ported from CCS's old forum
Original Post ID: 10023

[Neutone]

:=I have a most perplexing problem.
:=
:=I have a system that requires a real time clock. I wrote a program that used Timer 0 and it worked a treat. However, I have redesigned my system to use Timer 2 as a real-time clock, since I have a better use for Timer 0 and 1.
:=
:=Now my system hangs.
:=
:=The problem seems to lie in the DELAY assembly code added to the start of the absolute program listing and its' interaction with the interrupt dispatcher.
:=
:=My program will run ok, as long as the delay_ms routine is NOT interrupted by my Timer 2 ISR.
:=
:=As soon as the Timer 2 ISR is triggered (and exited, of course), I get trapped in DELAY.
:=
:=I'm confident it is not a problem with my code in the ISR, since, for testing purposes, I have just added a NOP there.
:=
:=If I DISABLE the timer 2 interrupt immediately before my delay_ms() line, and re-enable it immediately after the program works.
:=
:=I think the problem lies with CCS' interrupt dispatcher and its' entry and clean-up code. I'm using version 2.683 of the compiler. Is there a known bug in this version?
:=
:=Looking at the compiler generated code, I notice that the compiler adds three instructions to the end of my ISR - one to re-set the timer 2 flag (and the bit address is correct), 2 instructions to do something I don't understand with PCLATH. Does anyone know what those lines do?
:=
:=Also, looking at the inline DELAY code at the head of my absolute listing, I notice that it comprises several nested loops that manipulate W and several SFR's. I could imagine that the interrupt dispatcher could corrupt W on exit, just before the program counter returns to the DELAY routine, but I can't see how. The first thing the interrupt dispatcher does is store W in SFR 0x7F (at least I think it is 0x7F if memory serves; forgive the pun). But on exit, CCS' dispatcher does something very strange, instead of restoring W from 0x7F, it uses SWAP to exchange nibbles at 7F, then does another SWAP, storing the result in W. That seems crazy to me, but I can't see how it would make any difference.
:=
:=On the other hand, maybe the problem lies with the way CCS' interrupt dispatcher manipulates the program counter.
:=
:=Is this a compiler bug? Because it certainly looks like one to me.
:=
:=Searching the board I see some references to a mysterious "problem with 16F877.h in older versions of the compiler. What was this problem?
:=
:=Thanks for any help you can offer.

Have a look at this thread
<a href="http://www.pic-c.com/forum/general/posts/6403.html" TARGET="_blank">http://www.pic-c.com/forum/general/posts/6403.html</a>
___________________________
This message was ported from CCS's old forum
Original Post ID: 10029

[R.J.Hamlett]

:=I have a most perplexing problem.
:=
:=I have a system that requires a real time clock. I wrote a program that used Timer 0 and it worked a treat. However, I have redesigned my system to use Timer 2 as a real-time clock, since I have a better use for Timer 0 and 1.
:=
:=Now my system hangs.
:=
:=The problem seems to lie in the DELAY assembly code added to the start of the absolute program listing and its' interaction with the interrupt dispatcher.
:=
:=My program will run ok, as long as the delay_ms routine is NOT interrupted by my Timer 2 ISR.
:=
:=As soon as the Timer 2 ISR is triggered (and exited, of course), I get trapped in DELAY.
:=
:=I'm confident it is not a problem with my code in the ISR, since, for testing purposes, I have just added a NOP there.
:=
:=If I DISABLE the timer 2 interrupt immediately before my delay_ms() line, and re-enable it immediately after the program works.
:=
:=I think the problem lies with CCS' interrupt dispatcher and its' entry and clean-up code. I'm using version 2.683 of the compiler. Is there a known bug in this version?
:=
:=Looking at the compiler generated code, I notice that the compiler adds three instructions to the end of my ISR - one to re-set the timer 2 flag (and the bit address is correct), 2 instructions to do something I don't understand with PCLATH. Does anyone know what those lines do?
:=
:=Also, looking at the inline DELAY code at the head of my absolute listing, I notice that it comprises several nested loops that manipulate W and several SFR's. I could imagine that the interrupt dispatcher could corrupt W on exit, just before the program counter returns to the DELAY routine, but I can't see how. The first thing the interrupt dispatcher does is store W in SFR 0x7F (at least I think it is 0x7F if memory serves; forgive the pun). But on exit, CCS' dispatcher does something very strange, instead of restoring W from 0x7F, it uses SWAP to exchange nibbles at 7F, then does another SWAP, storing the result in W. That seems crazy to me, but I can't see how it would make any difference.
:=
This is the standard way of doing the interrupt register restore on the PIC.
The problem is that a simple 'MOV' instruction, sets the flag bits (Z, C etc.), depending on the contents of the byte moved. Swap doesn't do this. Since it is important to get the flag register restored as well, the SWAP method is used. :-)

:=On the other hand, maybe the problem lies with the way CCS' interrupt dispatcher manipulates the program counter.
:=
:=Is this a compiler bug? Because it certainly looks like one to me.
:=
:=Searching the board I see some references to a mysterious "problem with 16F877.h in older versions of the compiler. What was this problem?
:=
:=Thanks for any help you can offer.
Post the code you have in the interrupt. If you use any delay inside the interrupt, then there will be a problem, unless interrupts are disabled on delay routines. The compiler is meant to do this, but it is possible that your version has a fault with this.

Best Wishes
___________________________
This message was ported from CCS's old forum
Original Post ID: 10036

[PCM programmer]

:=I think the problem lies with CCS' interrupt dispatcher and its' entry and clean-up code. I'm using version 2.683 of the compiler. Is there a known bug in this version?
---------------------------------------------
There could be. Look at the following list of bug fixes
from the old CCS versions page. Look at what they said
for vs. 2.685. This is likely to be your problem. You may
have to fix it yourself. It's possible that there's some
info on it on the old board. You'll have to search for it.
<a href="http://www.pic-c.com/forum/old/" TARGET="_blank">http://www.pic-c.com/forum/old/</a>
You could load in the whole board and search for the word
"interrupt". I can't guarantee that an answer is there.

2.678 Only select bits in status register are now cleared in main
2.679 Compiler now checks that the combo of main and isr stack is ok
2.679 #reserve now allows xx:xx for a range of values
2.681 I2C_START problem is fixed
2.682 Increased number of allowed identifiers
2.683 #INT_BUSCOL and #INT_LOWVOLT have been added
2.684 printf \%ld and \%lu problem with banks 3&4 fixed
2.685 A serious interrupt problem (since 2.683) has been fixed
2.686 I2C clock streching now supported on the read ACK
2.687 #ORG functions that are never called now still compile to ROM
2.687 OSCCAL problem with PCM fixed
2.688 Another printf problem fixed
2.688 MPLAB hang problem on some .COD files fixed
2.689 Symbols in .LST file now show in MPLAB
2.690 An undeserved internal error #2 has been fixed


:=Also, looking at the inline DELAY code at the head of my absolute listing, I notice that it comprises several nested loops that manipulate W and several SFR's. I could imagine that the interrupt dispatcher could corrupt W on exit, just before the program counter returns to the DELAY routine, but I can't see how. The first thing the interrupt dispatcher does is store W in SFR 0x7F (at least I think it is 0x7F if memory serves; forgive the pun). But on exit, CCS' dispatcher does something very strange, instead of restoring W from 0x7F, it uses SWAP to exchange nibbles at 7F, then does another SWAP, storing the result in W. That seems crazy to me, but I can't see how it would make any difference.

Stephan Daystrom wrote an article on the CCS interrupt
handler for vs. 2.xxx of the compiler. See this link:
<a href="http://www.pic-c.com/forum/old/messages/470.html" TARGET="_blank">http://www.pic-c.com/forum/old/messages/470.html</a>
After each block of code, he has put in comments explaining
what it does.
-----------------------------------------------------------
:=
:=
:=Searching the board I see some references to a mysterious "problem with 16F877.h in older versions of the compiler. What was this problem?
------------------------
The problem was that CCS was redefining the "GLOBAL" constant,
so that Peripheral Interrupts were disabled. This resulted
in preventing most of the interrupts in the PIC from working.
You can tell if you've got this bad file, if it has these lines
near the bottom.

#undef GLOBAL
#define GLOBAL 0x0B80 // Used for ENABLE/DISABLE INTERRUPTS
#define INT_EEPROM 0x0B40 // Used for ENABLE/DISABLE INTERRUPTS

Just delete the upper two lines. GLOBAL is defined correctly
near the start of the file, as 0x0BC0.
Change INT_EEPROM to be 0x8D10.

This problem in 16F877.h was fixed by the time of your version,
PCM vs. 2.683. But a lot of people didn't bother to update
their "Examples" file (which contained the .h files) when they
downloaded a new version of the compiler. You'll have to
check your .h file and see if that's the case with you.
___________________________
This message was ported from CCS's old forum
Original Post ID: 10043

[PCM programmer]

:=:=I think the problem lies with CCS' interrupt dispatcher and its' entry and clean-up code. I'm using version 2.683 of the compiler. Is there a known bug in this version?
:=---------------------------------------------
:=There could be. Look at the following list of bug fixes
:=from the old CCS versions page. Look at what they said
:=for vs. 2.685. This is likely to be your problem. You may
:=have to fix it yourself. It's possible that there's some
:=info on it on the old board. You'll have to search for it.
:= <a href="http://www.pic-c.com/forum/old/" TARGET="_blank"> <a href="http://www.pic-c.com/forum/old/" TARGET="_blank">http://www.pic-c.com/forum/old/</a></a>
:=You could load in the whole board and search for the word
:="interrupt". I can't guarantee that an answer is there.
----------------------------------------------------------
I searched some archives I have from the old, old board,
and I found this message.

Posted by J.Price on September 29, 1999 at 12:16:06:
"I reported this bug to CCS and within 24 hours they had fixed
it, well done CCS. I am suprised that it was not noticed by
anybody else as it was a serious problem. In my case I was
using a number of interrupts but to pin down the problem I used
only one and found that the interrupt handler was checking
CCPR2H (1C) instead of PIE1(8C). I suspect this bug would give
problems to anybody using interrupts."



From that description, it sounds like CCS was not selecting
the proper bank before accessing PIE1 in the interrupt handler.
To fix that problem, you would probably have to write your
own interrupt handler. It's probably better to upgrade to
vs. 3.xxx.
___________________________
This message was ported from CCS's old forum
Original Post ID: 10053

[Ron]

I had a similar problem with delay_ms() and I2C interrupts on a PIC16C62.

When an I2C interrupt occurred, while the delay_ms() was running (or actually halting ), it would hang forever...

Until another SSP interrupt occured, it would continue just where it had stopped!!

I replaced the delay_ms() function by my own quick and dirty delay_altms() function and the stalls were solved.

//_____________________________________________________________// Maximum delay = 255 millisec
Delay_altms(Int Millisec)
{
Int t,t1;

For(t = 0; t < Millisec; t++)
{
#Define TIMESET 205
// 12 * 205 instructions = 2460 instructions =
//(1.00 ms @ 9.8304 MHz)
For(t1 = 0; t1 < TIMESET; t1++); // 6 * TIMESET instructions
For(t1 = 0; t1 < TIMESET; t1++); // 6 * TIMESET instructions
}
}

Best regards,
Ron


:=I have a most perplexing problem.
:=
:=I have a system that requires a real time clock. I wrote a program that used Timer 0 and it worked a treat. However, I have redesigned my system to use Timer 2 as a real-time clock, since I have a better use for Timer 0 and 1.
:=
:=Now my system hangs.
:=
:=The problem seems to lie in the DELAY assembly code added to the start of the absolute program listing and its' interaction with the interrupt dispatcher.
:=
:=My program will run ok, as long as the delay_ms routine is NOT interrupted by my Timer 2 ISR.
:=
:=As soon as the Timer 2 ISR is triggered (and exited, of course), I get trapped in DELAY.
:=
:=I'm confident it is not a problem with my code in the ISR, since, for testing purposes, I have just added a NOP there.
:=
:=If I DISABLE the timer 2 interrupt immediately before my delay_ms() line, and re-enable it immediately after the program works.
:=
:=I think the problem lies with CCS' interrupt dispatcher and its' entry and clean-up code. I'm using version 2.683 of the compiler. Is there a known bug in this version?
:=
:=Looking at the compiler generated code, I notice that the compiler adds three instructions to the end of my ISR - one to re-set the timer 2 flag (and the bit address is correct), 2 instructions to do something I don't understand with PCLATH. Does anyone know what those lines do?
:=
:=Also, looking at the inline DELAY code at the head of my absolute listing, I notice that it comprises several nested loops that manipulate W and several SFR's. I could imagine that the interrupt dispatcher could corrupt W on exit, just before the program counter returns to the DELAY routine, but I can't see how. The first thing the interrupt dispatcher does is store W in SFR 0x7F (at least I think it is 0x7F if memory serves; forgive the pun). But on exit, CCS' dispatcher does something very strange, instead of restoring W from 0x7F, it uses SWAP to exchange nibbles at 7F, then does another SWAP, storing the result in W. That seems crazy to me, but I can't see how it would make any difference.
:=
:=On the other hand, maybe the problem lies with the way CCS' interrupt dispatcher manipulates the program counter.
:=
:=Is this a compiler bug? Because it certainly looks like one to me.
:=
:=Searching the board I see some references to a mysterious "problem with 16F877.h in older versions of the compiler. What was this problem?
:=
:=Thanks for any help you can offer.
___________________________
This message was ported from CCS's old forum
Original Post ID: 10086