CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to CCS Technical Support

Workaround for FAST interrupt problem on PIC18F8722 Rev A1?

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
webbone



Joined: 20 Sep 2004
Posts: 14
Location: Sacramento, CA

View user's profile Send private message

Workaround for FAST interrupt problem on PIC18F8722 Rev A1?
PostPosted: Mon Aug 04, 2008 6:57 pm     Reply with quote

Per the A1 silicon errata sheet ( http://ww1.microchip.com/downloads/en/DeviceDoc/80221c.pdf ), there is a problem if a MOVFF instruction is used to operate on W, STATUS or BSR and that instruction is interrupted by a fast (high priority) interrupt.

Quote:
from Microchip Errata:
If an interrupt occurs during a two-cycle instruction
that modifies the STATUS, BSR or WREG register,
the unmodified value of the register will be saved
to the corresponding Fast Return (Shadow)
register and upon a fast return from the interrupt,
the unmodified value will be restored to the
STATUS, BSR or WREG register.
.
For example, if a high priority interrupt occurs
during the instruction, MOVFF TEMP, WREG, the
MOVFF instruction will be completed and WREG
will be loaded with the value of TEMP before
branching to ISR. However, the previous value of
WREG will be saved to the Fast Return register
during ISR branching. Upon return from the
interrupt with a fast return, the previous value of
WREG in the Fast Return register will be written to
WREG. This results in WREG containing the value
it had before execution of MOVFF TEMP, WREG.


Unfortunately, the CCS compiler (I'm using 3.234) uses MOVFF to restore these three registers in the low priority interrupt handler. Additionally unfortunate is the fact that for months I've been trying to get rev B silicon from Microchip with no luck, hence my hope for a software solution.

Is it possible to overwrite part of the interrupt handler with a #ROM directive? I.e. this would have to stomp over the code generated by the compiler - I can easily change the three MOVFF instructions to use MOVF and MOVWF to avoid the silicon bug but I'm unclear if there is a convenient way to do this. What I'm thinking code-wise is:

Code:

//CCS version
 000B6    C005     MOVFF 0x5, 0xfe8
 000BA    C007     MOVFF 0x7, 0xfe0
 000BE    C006     MOVFF 0x6, 0xfd8

//my version
000B6   MOVF  0x7,W, ACCESS
000B8   MOVWF 0xfe0, ACCESS
000BA   MOVF  0x6, W, ACCESS
000BC   MOVWF 0xfd8, F, ACCESS
000BE   SWAPF 0x5, W, ACCESS
000C0   SWAPF 0xfe8, W, ACCESS


As an alternative, did CCS ever implement a change of this sort prior to or in 3.249?

Any suggestions would be appreciated.

(edited to correct replacement assy)


Last edited by webbone on Wed Aug 06, 2008 5:50 pm; edited 1 time in total
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Mon Aug 04, 2008 8:47 pm     Reply with quote

If you want us to test this problem, then post a short but compilable test
program. Make it be very short, with 10-15 lines of code, max. It must
have the #include, #fuses, #use delay(), isr, main, and all necessary
variable declarations. It must compile without errors.
webbone



Joined: 20 Sep 2004
Posts: 14
Location: Sacramento, CA

View user's profile Send private message

PostPosted: Wed Aug 06, 2008 5:52 pm     Reply with quote

I wasn't looking for something to be tested, since the silicon bug on the 8722 IS causing trouble. And it would take a significantly longer example to guarantee that the problem would occur.

After some attempts it doesn't appear that there is any way to coax the compiler into stomping over what it generates so I'm going to have to revert to editing the .HEX file after compile (I was trying to avoid a two-stage process but I guess it's inevitable).
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Wed Aug 06, 2008 5:56 pm     Reply with quote

Right, but you asked this question:
Quote:
Did CCS ever implement a change of this sort prior to or in 3.249?

With a short little program, I can compile it with vs. 3.249 and see if
CCS fixed the problem in that version.

I don't need a carefully crafted program. All I need is a little test
program that has a interrupt routine defined in it, and that compiles
with no errors and without any edits required. I can then look at the
.LST file.
ckielstra



Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands

View user's profile Send private message

PostPosted: Thu Aug 07, 2008 1:12 pm     Reply with quote

Quote:
Unfortunately, the CCS compiler (I'm using 3.234) uses MOVFF to restore these three registers in the low priority interrupt handler.
If I understand the problem description than the CCS generated code is correct. It would have been a problem had the compiler returned from the interrupt with a 'fast return' instruction, assembly code RETFIE 1.

I don't have all the old versions but somewhere between v3.226 and v3.249 CCS gave fixed this problem by adding a new chip errata work around called 'Don't use RETFIE 1'. This is the behaviour shown in your code fragment so it looks like v3.234 does contain the fix. For double checking have a look at the configured errata in chipedit.exe.
ckielstra



Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands

View user's profile Send private message

PostPosted: Thu Aug 07, 2008 4:55 pm     Reply with quote

If I understand the problem description than the CCS generated code is correct. It would have been a problem had the compiler returned from the interrupt with a 'fast return' instruction, assembly code RETFIE 1.

Check chipedit.exe and you will see an errata is actived for this hardware bug.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group