 |
 |
| View previous topic :: View next topic |
| Author |
Message |
c_bellsham
Joined: 27 Oct 2005
Posts: 7
|
| 18F452 Interrupt Probelm |
 Posted: Thu Oct 27, 2005 3:03 am |
 |
|
Hi,
We are using CCS PCWH 3.212 for a PIC 18F452 project.
We think we've found a problem (that you may already be aware of) with the Low Priority interrupt.
It appears that the code generated for the inetrrupt vector 00018h doesn't save the STATUS register after saving the W register.
the code at vector 00008h does save the STATUS.
Is this a known problem?
Is there an update?
Or is there a snippet of code that someone could recomend |
|
 |
ckielstra
Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands
|
|
| Posted: Thu Oct 27, 2005 3:47 am |
|
|
| Quote: | It appears that the code generated for the inetrrupt vector 00018h doesn't save the STATUS register after saving the W register.
the code at vector 00008h does save the STATUS. |
Are you sure it is not the other way around; 0018h saving the status register and 008h skipping it?
When using both the Low and High priority interrupts, the high priority interrupts are located at 0008h. One feature of the high priority interrupts is that they automatically save the WREG, Status and BSR registers in hardware. |
|
|
c_bellsham
Joined: 27 Oct 2005
Posts: 7
|
|
| Posted: Thu Oct 27, 2005 4:59 am |
|
|
0008: MOVWF 05------------Saving W
000A: MOVFF FD8,06-------Saving Status
000E: MOVF FE9,W
0010: MOVWF 07
0012: MOVF FEA,W
0014: MOVWF 08
0016: MOVF FE1,W
0018: MOVWF 09-----------Saving W
001A: MOVF FE2,W--------Saving FSR using MOVF which affects Status!!!!!
001C: MOVWF 0A
001E: MOVF FD9,W
0020: MOVWF 0B |
|
|
Ttelmah
Guest
|
|
| Posted: Thu Oct 27, 2005 7:05 am |
|
|
Remember, that if the fast interrupt feature is not used, it is the low priority interrupt that sits at address 8. The code being shown, is the standard code for a system _only_ using low priority interrupts. Nothing will ever jump into this at address 18H.
If you enable hardware priority interrupts, then the code shown will be at address 18H, and at address 8, there will be a jump, to go 'round' this handler. This is one really annoying thing about the hardware design (it should be the low priority handler that stays at address 8).
I suspect you may be confusing the 'priority' command (which is only a command to alter the order in which the interrupt handlers are parsed in the code, ad pre-dates the introduction of hardware 'priorities'). The high priority interrupts require the 'high' command, and you can also use the 'FAST' command to allow the RETFIE 1 instruction (which automatically restores these registers).
the handler loaded with 'HIGH' used, is:
| Code: |
0000: GOTO 02FE
*
0008: GOTO 00A8
000C: NOP
000E: NOP
0010: NOP
0012: NOP
0014: NOP
0016: NOP
0018: NOP
001A: NOP
001C: MOVFF FE8,05
0020: MOVFF FD8,06
0024: MOVFF FE0,07
0028: MOVLB 0
002A: MOVFF FE9,0D
002E: MOVFF FEA,08
0032: MOVFF FE1,09
0036: MOVFF FE2,0A
003A: MOVFF FD9,0B
003E: MOVFF FDA,0C
0042: MOVFF FF3,14
0046: MOVFF FF4,15
004A: MOVFF FFA,16
|
That having been said, on 3.212, if you do use the 'HIGH' ability, you have to save the registers in the high priority handler. Automatic operation of this, was only introduced in latter compilers.
Best Wishes |
|
|
prwatCCS
Joined: 10 Dec 2003
Posts: 70
Location: West Sussex, UK
|
|
| Posted: Thu Oct 27, 2005 7:48 am |
|
|
I have sucessfully used v3.212 to generate code for the 18F252, 18F452 and 18F6621 using both High and Low (hardware) priority interrupts.
I have serial data at 250KB (fx and Rx irq) , timer0 and A2D conversion low prority interrupts and a Timer2 fast irq running.
Others have noted about the location of your irq vectors based on whether or not you are using both priorities, so I dont think you have correctly identified a problem. However, I would draw your attention to a problem I found with the use of the FAST irq code generation, whereby the compiler may incorrectly assume that Bank0 is mapped in on entry to the fast irq hander.
Please see my post titled 18fxx2/ compiler v2.236 FAST IRQ problem.
regards
_________________
Peter Willis
Development Director
Howard Eaton Lighting Ltd UK |
|
|
c_bellsham
Joined: 27 Oct 2005
Posts: 7
|
|
| Posted: Thu Oct 27, 2005 8:05 am |
|
|
Firstly, Many thanks for your help, I appreciate it!
We are trying to use both high and low priority interrupts.
Is there a way of telling the compiler that we are trying to use priority interrupts.
Currently we're only configuring the registers to do priority inetrrupts.
Does the compiler check what we are doing with these bits and then decide or is there a check box that we should be ticking? |
|
|
rnielsen
Joined: 23 Sep 2003
Posts: 852
Location: Utah
|
|
| Posted: Thu Oct 27, 2005 8:24 am |
|
|
I'm not sure if this has anything to do with what you're seeing but there was a bug fix for interrupts after v3.212.
| Quote: |
3.217 The PIC18 compiler now only disables low priority ints to prevent reentrancy
3.218 A bug with interrupt handling is fixed. If you use FAST ints see readme.txt.
|
|
|
|
Guest
|
|
| Posted: Thu Oct 27, 2005 8:35 am |
|
|
My approach is to place the #priority in my header file.
NOTE : this only sets the order in which the low (hardware) priority irqs are serviced, and has nothing to do with the FAST irq (aka high hardware priority)
| Code: | | #priority rda,timer1,timer0,tbe,ad |
when using FAST irqs on compiler versions later than 3.212 you also need
| Code: | #if getenv("VERSION") > 3.212
#device HIGH_INTS=TRUE
#endif |
Now for the various low priority irq handlers - they must exist before main() in your source file(s). The order they appear in the source is irrelevant, the order they are serviced is set by the #priority above.
| Code: | #int_RDA
RDA_irq()
{
//stuff
}
#int_TIMER1
TIMER1_irq()
{
//timer stuff
}
#int_TIMER0
TIMER0_irq()
{
// timer 0 stuff - I often us this as a 10ms timer which in turn runs 500ms/1second/1minute timers
}
#int_TIMER1
TIMER1_irq()
{
// more stuff
}
#int_TBE
TBE_isr()
{
// empty transmit buffer
}
etc |
Now for the FAST (aka high hardware priority). You only have ONE of these.
| Code: | #int_TIMER2 FAST
TIMER2_isr()
{
// stuff - keep it very simple and avoid fancy switch statements
// for loops etc so that you dont have to waste time context saving.
//
// best to keep to instructions that only use W, status and BSR as these are the only registers preserved by the hardware.
//
// ALWAYS check the compiler output and understand EXACTLY what it has produced.
//
// see my other bug report re Bank0 assumptions
} |
hope this helps  . I expect you knew most of this anyway.
regards
Peter Willis
andera@compuserve.com |
|
|
Ttelmah
Guest
|
|
| Posted: Thu Oct 27, 2005 8:53 am |
|
|
The _priority_ command, has nothing to do with using the high priority interrupt ability. All this does, is set the order in which the interrupts are scanned, inside the single global interrupt handler. It predates the introduction of high priority hardware interrupts.
The command for using high priority _hardware_ interrupts, is the 'HIGH' instruction, added after the interrupt declaration. So:
| Code: |
#INT_TBE HIGH /* Transmit buffer empty interrupt - high priority */
|
Now there are a lot of 'caveats' though. Firstly, look carefully at the data sheets for your chip. Most have some significat problems with some interrupt sources, or at the least some caveats about which interrupts can be used this way.
Secondly, on your compiler version, there is no code provided to actually do register saving in the high priority routines. You have to do all this.
FAST, _also_ has nothing to do with high priority interrupts!. It controls whether the RETFIE 1 'fast return' ability is used. Normally this would be used for a high priority interrupt as well, but it does not have to be...
If you are setting the bits yourself, then it is not suprising that the compiler is getting confused. Doing this, it has no idea that high priority interrupts are enabled, and will only provide one int_global handler at address 8. No wonder it does not work!. It is not able to see into your mind!.
The HIGH command has been around (and worked OK with careful programming), for several dozen compiler versions.
I'd say that if you want to use several hardware high priority interrupts, it would be worth upgrading, since with 3.231, there were some major changes in this area, that make it a lot easier to use.
Best Wishes |
|
|
c_bellsham
Joined: 27 Oct 2005
Posts: 7
|
|
| Posted: Thu Nov 17, 2005 8:05 am |
|
|
This is really starting to get on my wick.
I've added the line:-
#device PIC18F452 ICD=TRUE HIGH_INTS=TRUE
and I get the following error:-
Error 104 Extra Characters on the preprocessor command line.
So I removed that and tried the FAST:-
#int_LOWVOLT FAST
void LOWVOLT_isr(void)
And I get an error:-
Error 159 Invalid interrupt direcive Requires #device HIGH_INTS=TRUE
So I add that line back in and then I get both error 104 and 159
what the hell is going on with this dumb thing?
Or is it me? |
|
|
Guest
|
|
| Posted: Thu Nov 17, 2005 8:24 am |
|
|
Why not just put what it asks for, instead of trying to be 'smart', and put the commands onto one line?.
#include <18F452.h>
#device HIGH_INTS=true
Works fine for me.
Best Wishes |
|
|
dyeatman
Joined: 06 Sep 2003
Posts: 1934
Location: Norman, OK
|
|
| Posted: Thu Nov 17, 2005 8:27 am |
|
|
For what it's worth I see the same problem with version 3.236, but this compiles with no problems:
#include <18F452.h>
#device ICD=TRUE
#device HIGH_INTS=TRUE
P.S. Guest (TTelmah?), it seems you just beat me!!! |
|
|
Ttelmah
Guest
|
|
| Posted: Thu Nov 17, 2005 8:42 am |
|
|
It is amazing how often that happens... :-)
The compiler currently, is a bit 'undocumented' in this regard. It is 'odd' that commands like the ADC one, can be put on once line, or left seperate, but these new ones, seem to require the seperate lines.
Best Wishes |
|
|
|
|
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
