 |
 |
| View previous topic :: View next topic |
| Author |
Message |
webbone
Joined: 20 Sep 2004
Posts: 14
Location: Sacramento, CA
|
| Workaround for FAST interrupt problem on PIC18F8722 Rev A1? |
 Posted: Mon Aug 04, 2008 6:57 pm |
 |
|
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
|
|
| Posted: Mon Aug 04, 2008 8:47 pm |
|
|
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
|
|
| Posted: Wed Aug 06, 2008 5:52 pm |
|
|
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
|
|
| Posted: Wed Aug 06, 2008 5:56 pm |
|
|
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
|
|
| Posted: Thu Aug 07, 2008 1:12 pm |
|
|
| 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
|
|
| Posted: Thu Aug 07, 2008 4:55 pm |
|
|
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. |
|
|
|
|
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
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
