PIC 18F8720 Interrupt problems

[Graham Bremner]

Hi,
Currently when I am running a program and an interrupt is called then the whole PIC resets itself. I have ruled out the watchdog timer as I have disabled it and there is no change.
I have an Infa red reciever on INT_EXT1, I have enabled it and enabled global interrupts.
I have a program for the 16F877 using exactly the same interrupt code (apart form setting up the edge trigger) and it works fine.
The same problem occured when using INT_EXT2.
Does anyone have any ideas on this??

Thanks

Graham bremenr
___________________________
This message was ported from CCS's old forum
Original Post ID: 9969

[R.J.Hamlett]

:=Hi,
:= Currently when I am running a program and an interrupt is called then the whole PIC resets itself. I have ruled out the watchdog timer as I have disabled it and there is no change.
:=I have an Infa red reciever on INT_EXT1, I have enabled it and enabled global interrupts.
:=I have a program for the 16F877 using exactly the same interrupt code (apart form setting up the edge trigger) and it works fine.
:=The same problem occured when using INT_EXT2.
:=Does anyone have any ideas on this??
:=
First, what compiler version. The early version 3 compilers, generate some awful code for the 18 family chips...

Second, what functions do you use in the INT?. There is a significant difference in the way some code is generated between the two chips. On the 18F family, if you generate a 'switch' statement, without a 'default', it will generate a table based lookup, rather than using logic tests. Since table based lookups are also used for 'const' accesses, this results in the interrupts being disabled for massive sections of the main code (there are quite a few old threads about the latency this causes on this group). So you have to be aware of this, and if necessary alter the way code is written.

It is important to be aware that the #PRIORITY statement has a massively different behaviour between the two chip families. On the 16F chips, all this does, is change the order that the interrupts are tested for in the handler code. On the 18F family chips, there is hardware priority support, and this statement allows individual interrupts to be allocated to the high priority handler. A 'high priority' interrupt, can now interrupt a low priority handler, and there is no register save automatically performed in this case.

Obviously you must change any hardware register addresses used between the two chips.

If you use any assembler, have you looked at AN716, with regards to the address differences on RETLW calculations etc.

Again compiler verson is important, it is only recently, that some sections of the code have started working useably with these chips...

Best Wishes
___________________________
This message was ported from CCS's old forum
Original Post ID: 9970

[Graham Bremner]

HI,

Thanks, I got an updated version of PCWH and the code worked Ist time.

Cheers

Graham Bremner
___________________________
This message was ported from CCS's old forum
Original Post ID: 10019

[R.J.Hamlett]

:=HI,
:=
:=Thanks, I got an updated version of PCWH and the code worked Ist time.
:=
:=Cheers
Good.
As you saw, that was #1 on the list of possibilities. The number of threads on interrupt problems with the 18F family (which were very frequent a few months ago), has declined now as the code has improved. :-)

Best Wishes
___________________________
This message was ported from CCS's old forum
Original Post ID: 10020