Searching \ for '[PIC]: Help! :) Error with FSR0 and MPLAB-C18?' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/languages.htm?key=mplab
Search entire site for: 'Help! :) Error with FSR0 and MPLAB-C18?'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: Help! :) Error with FSR0 and MPLAB-C18?'
2001\01\10@162358 by Jeff Meyer

flavicon
face
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_OUTlistservTakeThisOuTspammitvma.mit.edu with SET PICList DIGEST in the body


2001\01\11@090517 by Olin Lathrop

face picon face
>   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, .....olinKILLspamspam@spam@embedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestspamKILLspammitvma.mit.edu


2001\01\11@094014 by Jeff Meyer

flavicon
face
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-requestKILLspamspam.....mitvma.mit.edu


2001\01\11@161335 by Jeff Meyer

flavicon
face
Sorry, I forgot to put the last bit of code that restores the data:

00154c   0e02     MOVLW     0x2
00154e   5ee1     SUBWF     0xe1,0x1,0x0

001550   cfe5     MOVFF     0xfe5,0xfd9

001552   ffd9

001554   cfe5     MOVFF     0xfe5,0xfea

001556   ffea

001558   cfe5     MOVFF     0xfe5,0xfe9

00155a   ffe9
00155c   0011     RETFIE    0x1

FE5=POSTDEC1

Thanks,
Jeff.

--
http://www.piclist.com hint: To leave the PICList
EraseMEpiclist-unsubscribe-requestspam_OUTspamTakeThisOuTmitvma.mit.edu


2001\01\11@175000 by Olin Lathrop

face picon face
> I should also note that the procedure that is being interrupted is meant
to
> be reentrant.

This smells like a stack overflow problem.


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, olinspamspam_OUTembedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: To leave the PICList
@spam@piclist-unsubscribe-requestKILLspamspammitvma.mit.edu


2001\01\14@100347 by Andrew E. Kalman

flavicon
face
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.   KILLspamaekKILLspamspampumpkininc.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

flavicon
face
>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 RemoveMElistservTakeThisOuTspammitvma.mit.edu with SET PICList DIGEST in the body


2001\01\15@131452 by Andrew E. Kalman

flavicon
face
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.   spamBeGoneaekspamBeGonespampumpkininc.com

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email TakeThisOuTlistservEraseMEspamspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body


2001\01\16@104838 by Jeff Meyer

flavicon
face
> Below is a clip out of some working code.
>
>
>#elif OSCOMPILER == OSMPLAB_C18 && OSTARGET == OSPIC18
>#pragma interrupt IntVector save=section(".tmpdata"),PROD
>
Thanks!  This worked like a charm!  BTW, where did you find the "section"
statement?

Jeff.

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestspamTakeThisOuTmitvma.mit.edu


More... (looser matching)
- Last day of these posts
- In 2001 , 2002 only
- Today
- New search...