12F675 interrupt problems - 3.119

john cutler · Joined: 06 Sep 2003 Posts: 82 Location: Hot Tub, California

After much hair pulling and after scruitinizing the interrupt code generated by the new 3.119 compiler, I'm pretty sure that it is generating bogus code. At the beginning of my asm listing, it shows the same code as an earlier version 3.103, but then, after the RETFIE statement, it adds a "CALL 3FF" which I can't figure out at all. Anyone have any ideas?
___________________________
This message was ported from CCS's old forum
Original Post ID: 8418

R.J.Hamlett · Guest

:=After much hair pulling and after scruitinizing the interrupt code generated by the new 3.119 compiler, I'm pretty sure that it is generating bogus code. At the beginning of my asm listing, it shows the same code as an earlier version 3.103, but then, after the RETFIE statement, it adds a "CALL 3FF" which I can't figure out at all. Anyone have any ideas?
If it is after the retfie, then it is not part of the interrupt code.
Call 0x3FF, is the instruction needed to access the OSCCAL value, which is normally done by default on the newer compilers. I presume it just happens to be putting it's routine to do this, immediately after the interrupt handler.

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

R.J.Hamlett · Guest

:=After much hair pulling and after scruitinizing the interrupt code generated by the new 3.119 compiler, I'm pretty sure that it is generating bogus code. At the beginning of my asm listing, it shows the same code as an earlier version 3.103, but then, after the RETFIE statement, it adds a "CALL 3FF" which I can't figure out at all. Anyone have any ideas?
Carrying on from what I allready said, you should be aware, that because of this instruction, if you are reprogramming the part, it is vital that you save the instruction from the 3FF address, and restore it when you program new code. Otherwise, depending on what value is written to the 3FF address, the call can end up resulting in an infinite loop...

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

johnpcunningham · Guest

The CALL 0x3FF statementwill occur when you are using the internal clock. The 12F parts are shipped with a calibration value and a retlw op-code.

To fix your problem add this to your code:

#ROM 0x3ff = {0x349C}

0x3FF gives the location, 0x34 is the opcode for retlw, and the 0x9c is the calibration value.

If you were using the larger 12F device you would do this:
#ROM 0x1fff = {0x349C}

JC
___________________________
This message was ported from CCS's old forum
Original Post ID: 8429

john cutler · Joined: 06 Sep 2003 Posts: 82 Location: Hot Tub, California

:=:=After much hair pulling and after scruitinizing the interrupt code generated by the new 3.119 compiler, I'm pretty sure that it is generating bogus code. At the beginning of my asm listing, it shows the same code as an earlier version 3.103, but then, after the RETFIE statement, it adds a "CALL 3FF" which I can't figure out at all. Anyone have any ideas?
:=If it is after the retfie, then it is not part of the interrupt code.
:=Call 0x3FF, is the instruction needed to access the OSCCAL value, which is normally done by default on the newer compilers. I presume it just happens to be putting it's routine to do this, immediately after the interrupt handler.
:=
:=Best Wishes

Thanks a lot you guys...OSC CAL was the problem. I'd only glanced at the literature about it - it's never caused me problems before. Now I get to see if my program works!!!
Thanks again.

John
___________________________
This message was ported from CCS's old forum
Original Post ID: 8434

Lance Lascari · Guest

I'm a little new to the forum and compiler (bought it about 8 releases ago which was only a month).

Anyway, one of the first problems I found was that the 12f629 OSCCAL register was set to the wrong address (fix in the device editor). Also, the ram size was wrong...

That was causing mine to fail all RS232 comms because the frequency was so far off. I emailed them way back when, but it seems that they've got a lot of issues to fix first.

I'm working on a win2k based programmer where I'm handling the "read the cal then write" business automatically -- so I've spent a fair amount of time working on/around this area. I suggest "cataloging" devices you have with the cal info, so that when you inevitably blow it away you can restore your parts. I literally had to use a spectrum analyzer to get the clock of mine back on the right spot, I was surprised how far you can move the frequency!

I'll stop rambling now.

Just be careful (12f675 almost identical to '629)

Lance

:=:=After much hair pulling and after scruitinizing the interrupt code generated by the new 3.119 compiler, I'm pretty sure that it is generating bogus code. At the beginning of my asm listing, it shows the same code as an earlier version 3.103, but then, after the RETFIE statement, it adds a "CALL 3FF" which I can't figure out at all. Anyone have any ideas?
:=If it is after the retfie, then it is not part of the interrupt code.
:=Call 0x3FF, is the instruction needed to access the OSCCAL value, which is normally done by default on the newer compilers. I presume it just happens to be putting it's routine to do this, immediately after the interrupt handler.
:=
:=Best Wishes
___________________________
This message was ported from CCS's old forum
Original Post ID: 8470