> The odd thing is the delay routine that's playing up works perfectly
> when I move it closer to the front of the code. Then the routine(s) at
> the end go west. It's as if no routine itself is faulty, but the
> execution is!

So it was not the case with the PCLATH thingy?

BTW: Is not it OSCCAL value at 7FF? Your programmer might not even let you
place a code over there to avoid overwriting the OSCCAL value like that. Try
to put this diagnostic sniplet before - like turn on a pin and "goto $"
would do as it 'should not be happen'.

Tamas



On 9/24/07, David Duffy (AVD) <david@audiovisualdevices.com.au> wrote:
>
> Thanks guys. I've combined all the questions and answers to save
> bandwidth.
>
> > I don't see why, but is the CMCON register causing a problem perhaps?
> >
>
> I'm disabling the comparators as per many other projects.
>
> > Have you tried a different 628a from a different batch?
> >
>
> Yes, three different batches. I'll check with a "non-A" version tomorrow.
>
> > Does the uC use sleep - there is an errata for some silicon, causes
> unexpected program execution.
> >
>
> No sleep involved. (especially for me!)
>
> > Perhaps the config word is corrupted when programming?
> > I've had a similar problem with a 648, which disappeared when I used a
> different compiler and the ASM by both looked OK, so must have been a hex
> file corruption.
> >
>
> Maybe something to check. I may have to reinstall an older version of
> MPLAB although thinking about it I used the same version, PC and
> PicStart+ to do the other (working) project.
>
> > Uninitilized variables could be likely cause. Or set of input data,
> > which was not simulated.
>
> No inputs really. All variables are cleared before use.
>
> > Stack Overflow?...
>
> Only 2 levels deep at the time of the problem. Not an underflow either
> says the simulator.
>
> > Are you sure you're wrapping around?  Have you considered adding some
> > "debugging output" at the end of memory to ensure it is rolling
> > around?   It also occurs to me that depending on your code, it could
> > be that you're somehow being redirected to the interrupt vector from a
> > toggling pin.
>
> Actually, I tried a sleep instruction or setting a diagnostic pin at
> 0x7ff but it doesn't actually seem to roll through there. I'm not really
> sure where it's jumping to now!
>
> > Are you able to use the ICD debugging stuff?   That might help you
> > figure out what is going on there.
>
> I do have an ICD but have never learned to use it. The board is not
> setup for ICP either. :-(
>
> > I've also seen power supply stability cause brownout resets....
>
> Checked PSU and all pins for out-of-spec voltage and instability using
> DMM and CRO.
>
> > If execution wraps around to the beginning, I would guess you have no
> return or
> > goto at the end or last routine to return to your main loop.
> >
>
> No missing returns that I can see. No calls instead of goto's or
> visa-versa either.
>
> > Or you have something causing a device reset.
>
> It is indeed getting back to the reset vector as I can see the start-up
> code executing every xx (will have to measure) milliseconds. It's very
> regular but watchdog is off at present. That was my first thought.
>
> The odd thing is the delay routine that's playing up works perfectly
> when I move it closer to the front of the code. Then the routine(s) at
> the end go west. It's as if no routine itself is faulty, but the
> execution is!
> David...
> --
> http://www.piclist.com PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist