Exact match. Not showing close matches.
PICList
Thread
'[PIC]: Help! :) Error with FSR0 and MPLAB-C18?'
2001\01\10@162358
by
Jeff Meyer
|
It seems that I am encountering an error in MPLAB-C18. I have a procedure
that has a parameter passed to it. That parameter is used as an index into
an array of structures. If that procedure is interrupted, when the
interrupt handler returns, the wrong index is used to finish the
assignments. For example, if this is the code that is running (ID is the
parameter, and is equal to 1 before the interrupt):
DEBUG_ROLL=TIMERS[ID].ROLLOVERS_LEFT;
** Interrupt occurs here **
DEBUG_ELAPSED=TIMERS[ID].ELAPSED;
DEBUG_TIME=TIMERS[ID].TIME;
When the return from interrupt occurs, ID is now 0. So the code ends up
indexing the wrong element of the array...
Anybody else seen anything like this? What should I post to help out?
Thanks,
Jeff Meyer
Rockwell Collins, Inc.
--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spam_OUTlistservTakeThisOuT
mitvma.mit.edu with SET PICList DIGEST in the body
2001\01\11@090517
by
Olin Lathrop
> DEBUG_ROLL=TIMERS[ID].ROLLOVERS_LEFT;
>
> ** Interrupt occurs here **
>
> DEBUG_ELAPSED=TIMERS[ID].ELAPSED;
> DEBUG_TIME=TIMERS[ID].TIME;
>
> When the return from interrupt occurs, ID is now 0. So the code ends up
> indexing the wrong element of the array...
Sounds like the interrupt is trashing some state. Is the interrupt routine
saving/restoring FSR? Take a look at the assembly code generated for the
lines above and see what resources it uses.
*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, .....olinKILLspam
@spam@embedinc.com, http://www.embedinc.com
--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-request
KILLspammitvma.mit.edu
2001\01\11@094014
by
Jeff Meyer
|
Here is the assembly code generated for the first part of the interrupt
handler:
0014fa cfe7 MOVFF 0xfe7,0xfe6 void Interrupt_Handler(void) {
0014fc ffe6
0014fe cfe9 MOVFF 0xfe9,0xfe6
001500 ffe6
001502 cfea MOVFF 0xfea,0xfe6
001504 ffe6
001506 cfd9 MOVFF 0xfd9,0xfe6
001508 ffe6
00150a cfe1 MOVFF 0xfe1,0xfd9
00150c ffd9
00150e 0e01 MOVLW 0x1
001510 26e1 ADDWF 0xe1,0x1,0x0
unsigned char TEMP;
001512 a4f2 BTFSS 0xf2,0x2,0x0 if (INTCONbits.TMR0IF) {
The registers for the 18C452 are:
FE7=INDF1
FE6=POSTINC1
FE9=FSR0L
FEA=FSR0H
FD9=FSR2L
FE1=FSR1L
Upon further testing and analysis, it seems that I may have misstated the
original problem. I don't know if it is just FSR0 getting corrupted, or if
it is more than that. I originally thought that the index term (ID) was
being corrupted, but it looks like the entire data stack is behaving funny.
I should also note that the procedure that is being interrupted is meant to
be reentrant. This is the reason I found this "bug" in the first place.
One of the interrupts that can interrupt the procedure is the serial data
interrupt. If that happens, the same procedure is called by the serial
data interrupt handler (with a different value for ID).
Thanks for the help ,
Jeff.
--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-requestKILLspam
.....mitvma.mit.edu
2001\01\11@161335
by
Jeff Meyer
2001\01\11@175000
by
Olin Lathrop
2001\01\14@100347
by
Andrew E. Kalman
Re:
>
>When the return from interrupt occurs, ID is now 0. So the code ends up
>indexing the wrong element of the array...
>
Make sure you are saving the temporary data segment in the
declaration for your ISR -- I think it's called ".tmpdata".
Also, make sure you have the latest and greatest version of MPLAB-C18
-- several updates occurred in the past few months, and I, too was
bitten by a int-save bug until I got the update AND I additionally
saved that segment.
--
______________________________________
Andrew E. Kalman, Ph.D. KILLspamaekKILLspam
pumpkininc.com
--
http://www.piclist.com hint: The PICList is archived three different
ways. See http://www.piclist.com/#archives for details.
2001\01\15@111829
by
Jeff Meyer
>Make sure you are saving the temporary data segment in the
>declaration for your ISR -- I think it's called ".tmpdata".
Andrew,
Thanks for the reply. I heard something like this from the guys at
Microchip as well. I did try to save the ".tmpdata" area, but I could not
get the syntax right (I kept getting invalid symbol errors and what not.)
Do you remember the correct way to do this? I have tried numerous things,
including:
#pragma interrupt Interrupt_Handler save=.tmpdata
#pragma interrupt Interrupt_Handler save=tmpdata
but I (of course) get the "invalid symbol" or "symbol name expected"
errors.
I also have MPLAB-C18 v 1.00.13.
Thanks,
Jeff.
--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservTakeThisOuT
mitvma.mit.edu with SET PICList DIGEST in the body
2001\01\15@131452
by
Andrew E. Kalman
|
Hi Jeff.
Re:
>Thanks for the reply. I heard something like this from the guys at
>Microchip as well. I did try to save the ".tmpdata" area, but I could not
>get the syntax right (I kept getting invalid symbol errors and what not.)
>Do you remember the correct way to do this? I have tried numerous things,
>including:
Below is a clip out of some working code. Sorry about the delay in my
original posting -- the PICLIST server rejected it for about a week
before it showed up.
***** begin code section *******
#elif OSCOMPILER == OSMPLAB_C18 && OSTARGET == OSPIC18
void IntVector ( void );
/* locator for high-priority ISR */
#pragma code highVector = 0x08
void athighVector ( void )
{
_asm GOTO IntVector _endasm
}
#pragma code /* end of ISR locator */
#pragma interrupt IntVector save=section(".tmpdata"),PROD
void IntVector( void )
{
if ( TMR2IE && TMR2IF )
{
TMR2IF = 0;
OSTimer();
}
PORTB ^= 0x20;
}
#endif /* #if OSCOMPILER == OSHT_PICC etc. */
--
______________________________________
Andrew E. Kalman, Ph.D. spamBeGoneaekspamBeGone
pumpkininc.com
--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email TakeThisOuTlistservEraseME
spam_OUTmitvma.mit.edu with SET PICList DIGEST in the body
2001\01\16@104838
by
Jeff Meyer
More... (looser matching)
- Last day of these posts
- In 2001
, 2002 only
- Today
- New search...