Ok, so I am a begginer and this is my first post!
I've been working on various PIC prjects building some skills, and I have
recently tried, to make a clock that counts upto 10 minutes on 3 7segs. All
seems to work well apart from after 35 seconds it seems, to just jump out of
the loop and go back as if it had been reset. It happens in MPLAB aswell as
in the real thing. You can watch it all of the sudden go back and reload
the INIT part of the program.
I am using TMR0 on a 16f84, using the overflow interrupt.
I do have WDT disabled. I think I was having a similar problem before, but
like every second, however after jiggling all the code around it worked for
longer.
The only thing I can think of is something to do with the interrrupt
happening at a particular point and the PC going screwy. But I am otherwise
baffled!
I can supply the source if that helps, (am I allowed?)
Cheers
Ed
- Oh and ultimately im trying to make some sort of a bike computer for fun,
anyone have any ideas where i could get more info on such a project!
> The only thing I can think of is something to do with the interrrupt
> happening at a particular point and the PC going screwy. But I am
otherwise
> baffled!
Bingo, I would look into this. You are probably getting an interrupt when
you are switched to BANK1 in main level and then the interrupt routine is
returning with BANK0 selected. Your main level code then stomps the wrong
configuration register. Your interrupt routine may be setting the BANK and
not restoring it to the one that was selected when the interrupt routine was
entered. The most important thing with interrupts is that you have to put
absolutely everything back like it was when the interrupt occured. The
microchip docs make a big deal out of STATUS and W, but they don't really
mention about saving FSR, the current BANKx and a few other things you might
be using. Go thru your main level code and try to imagine an interrupt
occurring between any two instructions, eventually that is what happens at
run time. If your program is not responding to any external stimulus, the
program will run exactly the same way every time allowing the "disaster" to
occur at exactly the same amount of time after power up.
PS: been there done that, pulling my hair out trying to figure out how the
impossible was happening. You'll find it, and then it'll make perfect
sense. ;-)
On Mon, 11 Mar 2002 19:38:42 -0600, michael brown wrote:
>> The only thing I can think of is something to do with the interrrupt
>> happening at a particular point and the PC going screwy. But I am
>otherwise
>> baffled!
>
>Bingo, I would look into this. You are probably getting an interrupt when
>you are switched to BANK1 in main level and then the interrupt routine is
>returning with BANK0 selected. Your main level code then stomps the wrong
>configuration register. Your interrupt routine may be setting the BANK and
>not restoring it to the one that was selected when the interrupt routine was
>entered. The most important thing with interrupts is that you have to put
>absolutely everything back like it was when the interrupt occured. The
>microchip docs make a big deal out of STATUS and W, but they don't really
>mention about saving FSR, the current BANKx and a few other things you might
>be using.
I think that the reason Microchip is so explicit about STATUS and W is
that's it's really tough to do *anything* without affecting them in
some way. If your interrupt routine modifies FSR, then, obviously, it
needs to be saved and restored but saving and restoring STATUS will
take care of your bank bits, won't it?
Regards, Bob
>Go thru your main level code and try to imagine an interrupt
>occurring between any two instructions, eventually that is what happens at
>run time.
It might be more productive to first re-check the interrupt routine
itself to ensure that it isn't modifying something that it's not
preserving across interrupts. Anything used in the interrupt routine
is suspect but can be desk-checked for being properly preserved across
the call.
I wrote:
>> The
>>microchip docs make a big deal out of STATUS and W, but they don't really
>>mention about saving FSR, the current BANKx and a few other things you
might
>>be using.
Then Bob wrote:
>I think that the reason Microchip is so explicit about STATUS and W is
>that's it's really tough to do *anything* without affecting them in
>some way. If your interrupt routine modifies FSR, then, obviously, it
>needs to be saved and restored but saving and restoring STATUS will
>take care of your bank bits, won't it?
This is true about the STATUS reg and the BANK as far as the main level will
be ok, but the interrupt routine may not realize that it's in BANK1 when it
tries to reload TMR0 and clobbers the OPTION register. :-O To be honest,
I've been cheating on the side (with some other micros) and am a little
rusty on the PIC minutiae right now. ;-) I was just trying to point out
that there are a few more "gotcha's" than the datasheet "clearly" indicates.
;-)
Regards, Bob
>>Go thru your main level code and try to imagine an interrupt
>>occurring between any two instructions, eventually that is what happens at
>>run time.
>It might be more productive to first re-check the interrupt routine
>itself to ensure that it isn't modifying something that it's not
>preserving across interrupts. Anything used in the interrupt routine
>is suspect but can be desk-checked for being properly preserved across
>the call.
True again, but I still will bet on the OPTION register or jmp'ing across
pages. ;-)
> I've been working on various PIC prjects building some skills, and I have
> recently tried, to make a clock that counts upto 10 minutes on 3 7segs.
All
> seems to work well apart from after 35 seconds it seems, to just jump out
of
> the loop and go back as if it had been reset. It happens in MPLAB aswell
as
> in the real thing. You can watch it all of the sudden go back and reload
> the INIT part of the program.
If you can watch it happen then what's the problem!? Go track it down.
What is it doing when it gets "interrupted", where does it go?
If it goes to location 4, you are probably getting an interrupt. If it goes
elsewhere, I bet you forgot to set PCLATH on a jump somewhere.
> If your interrupt routine modifies FSR, then, obviously, it
> needs to be saved and restored but saving and restoring STATUS
> will take care of your bank bits, won't it?
Yes. You are also right in that you only need to save FSR if it is used
inside the interrupt routine. However, you need to save PCLATH ***and then
clear it*** before doing any GOTOs or CALLs in the interrupt routine.
I use a template for interrupt modules that has all this built in. See
QQQ_INTR.ASPIC at http://www.embedinc.com/pic.
>
> I think that the reason Microchip is so explicit about STATUS and W is
> that's it's really tough to do *anything* without affecting them in
> some way. If your interrupt routine modifies FSR, then, obviously, it
> needs to be saved and restored but saving and restoring STATUS will
> take care of your bank bits, won't it?
>
>
> Regards, Bob
>
That's the problem though... where are you saving STATUS. Unless you save
it in a register mapped to all banks, you have the possibility of messing
some things up.
mitvma.mit.edu with SET PICList DIGEST in the body
