View previous topic :: View next topic |
Author |
Message |
Matro Guest
|
#INT_GLOBAL : Error : Unprotected call |
Posted: Thu Mar 13, 2008 3:47 am |
|
|
Hello,
I'm in trouble with #INT_GLOBAL.
Below is the code I use:
Code: |
#LOCATE W_save = 0x7F
#LOCATE STATUS_save = 0x7E
#LOCATE FSR_save = 0x7D
#LOCATE PCLATH_save = 0x7C
#BYTE STATUS = 0x03
#BYTE FSR = 0x04
#BYTE PCLATH = 0x0A
#BIT SSPIF = 0x0C.3
#BIT TMR1IF = 0x0C.0
#BIT TMR0IF = 0x0B.0
//Handle the general Interrupt
#int_GLOBAL
void GLOBAL_isr(void)
{
#ASM
MOVWF W_save
SWAPF STATUS, w
MOVWF STATUS_save
MOVF FSR, w
MOVWF FSR_save
MOVF PCLATH, w
MOVWF PCLATH_save
#ENDASM
if(SSPIF)
SSP_isr();
if(TMR1IF)
TIMER1_isr();
if(TMR0IF)
TIMER0_isr();
#ASM
MOVF PCLATH_save, w
MOVWF PCLATH
MOVF FSR_save, w
MOVWF FSR
SWAPF STATUS_save, w
MOVWF status
SWAPF W_save, f
SWAPF W_save, w
#ENDASM
}
|
The compilation return :
"Error 134 : Unprotected call in a #INT_GLOBAL".
Does somebody know what exactly create this error and how to avoid it?
Chip : PIC16F88
CCS ver. : 4.069
Thanks in advace,
Matro[/code] |
|
|
Ken Johnson
Joined: 23 Mar 2006 Posts: 197 Location: Lewisburg, WV
|
|
Posted: Thu Mar 13, 2008 8:39 am |
|
|
What do the functions SSP_ISR, etc look like? I'm assuming one of these is the culprit . . .
Ken |
|
|
Matro Guest
|
|
Posted: Thu Mar 13, 2008 8:58 am |
|
|
It's seems that you're right.
I tried with calls to some different interrupt routines and the error appears as soon as an interrupt routine calls a function.
The strange thing is that there is no problem when using the automatically generated interrupt dispatcher. But appears when I used my own.
The base of my problem is actually that in the case of the CCS dispatcher, the interrupt flags are cleared at the end of the interrupt routines.
I'd like it to be cleared before (easy 'cause I can do it manually) but not to be cleared at the end of the function (seems impossible with the CCS options).
If somebody has an idea of how to do so... :-)
Thanks for your perspicacity Ken. ;-) |
|
|
Ken Johnson
Joined: 23 Mar 2006 Posts: 197 Location: Lewisburg, WV
|
|
Posted: Thu Mar 13, 2008 10:07 am |
|
|
#INT_xxxx NOCLEAR
The NOCLEAR option tells CCS not to do it - so do it yourself.
I find it curious that ccs clears it at the end, not beginning - seems like it's always best to clear first ? ? ?
Ken |
|
|
RLScott
Joined: 10 Jul 2007 Posts: 465
|
|
Posted: Thu Mar 13, 2008 10:22 am |
|
|
Ken Johnson wrote: | #INT_xxxx NOCLEAR
The NOCLEAR option tells CCS not to do it - so do it yourself.
I find it curious that ccs clears it at the end, not beginning - seems like it's always best to clear first ? ? ?
Ken |
Some interrupts, like Interrupt-on-change or UART Rx, cannot be cleared until you do something first - like read the port in interrupt-on-change, or read the Rx register in async serial.
Robert Scott
Real-Time Specialties |
|
|
Matro Guest
|
|
Posted: Thu Mar 13, 2008 10:46 am |
|
|
Ken Johnson wrote: | #INT_xxxx NOCLEAR
The NOCLEAR option tells CCS not to do it - so do it yourself.
I find it curious that ccs clears it at the end, not beginning - seems like it's always best to clear first ? ? ?
Ken |
Exactly what I need. Thanks for that.
I find it strange too but that's what I have and that is a problem.
But with the tip you just gave it gonna be OK.
Thanks again.
Matro |
|
|
Matro Guest
|
|
Posted: Thu Mar 13, 2008 10:50 am |
|
|
RLScott wrote: | Ken Johnson wrote: | #INT_xxxx NOCLEAR
The NOCLEAR option tells CCS not to do it - so do it yourself.
I find it curious that ccs clears it at the end, not beginning - seems like it's always best to clear first ? ? ?
Ken |
Some interrupts, like Interrupt-on-change or UART Rx, cannot be cleared until you do something first - like read the port in interrupt-on-change, or read the Rx register in async serial.
Robert Scott
Real-Time Specialties |
I don't fully agree with you because I never saw this behavior in a PIC16.
For example, in UART RX, you don't have to directly clear the interrupt flag (in fact you can't) becouse the ONLY way to do so is to read the RX buffer.
So in this case, my question doesn't exist. ;-)
Thanks for taking time participating to this thread.
Matro. |
|
|
|