> Hi there,
> It's been some time since I've needed the assistance of this list but
> I've come up against an odd problem. It's probably something really
> simple (stupid) but it's got me stumped.
>
> I'm working on a small project using assembler and a 16F628A-I/P. The
> code simulates perfectly but when run on the acutual chip, it spins off
> into program space when I call the routine at the end of my asm file and
> seems to wrap around to the beginning of the program. I can see some
> pins that I toggle at startup just continually doing so.
>
> Things I've checked are:
>     I'm not fiddling with the PCL
>     All the code fits in under about 0x2ce
>     The watchdog is not turned on
>
> When I move the routine in question dow to the "front of the code" it
> works, but then the new one at the end fails. These routines are direct
> copies from another project of mine which works perfectly. Can anyone
> suggest anything please?
> David...

>
> 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...

>
> Tamas Rudnai wrote:
> >> 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'.
> >
>
> Good point. I'd forgotten about the trim for the internal RC in this chip.
> I just added a diagnostic pin BSF (and wait loop) at 0x7f0 and it still
> resets.
> David...

>
> Both TO and PD indicate that a wdt or wake from sleep has not occurred.
> All I'm doing is calling the affected routine like this:
>
> start:
> bank0 ;start in ram bank 0
> call clear_ram ;
> call initialise ;initialise registers, etc
> bsf l_red ;turn red led on
> call delay_250 ;wait 250ms
> bcf l_red ;turn red led off
> ...
>
> It's spinning off into space during the delay_250 routine.
> David...
>
> Tamas Rudnai wrote:
> > Do you have testing routine in the reset area so that you can find out
> what
> > type of reset you have?
> > Can you show the code especially how you call that routine?
> >

>
> James Hillman wrote:
> >> Both TO and PD indicate that a wdt or wake from sleep has not occurred.
> >> All I'm doing is calling the affected routine like this:
> >>
> >> start:
> >> bank0 ;start in ram bank 0
> >> call clear_ram ;
> >> call initialise ;initialise registers, etc
> >> bsf l_red ;turn red led on
> >> call delay_250 ;wait 250ms
> >> bcf l_red ;turn red led off
> >> ...
> >>
> >> It's spinning off into space during the delay_250 routine.
> >>
> >
> > Could an interrupt be occurring during the delay - a timer perhaps
> > inadvertently set-up during initialise?
> >
>
> I've disabled GIE and the fault persists.
>
> > In the initialise routine have you used code intended for a different
> > processor that may have had Special Function registers in different
> banks to
> > the processor you are now using?
> >
>
> No, init routine taken from a known good project using the same chip.
>
> > Does any bank switching occur during the delay?
> > Does it go 'spinning off' after a specific time ( you could reduce the
> delay
> > until you find this )
>
> No bank switching in the delay routine.
> David...

>
> Jinx wrote:
> >> 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.
> >>
> >
> > Several times I've noticed that MPASM doesn't pick up on typos.
> > The most recent was when I used, from memory, the variable name
> > op_stat. The compilation appeared to go OK. However, the real
> > variable name I should have used was o_stat. Took lots of debugging
> > to find that where op_stat had been used, there was no code made.
> > For example movf op_stat,w was simply ignored. Replacing op_stat
> > with o_stat fixed it all. Perhaps you should check carefully for typos
> >
> > (apologies if I've forgotten the original problem)
> >
> >
> The worst problem I noticed was old MPASM not handling "pagesel"
> properly. That drove me crazy until
> I finally found it. I simply created my OWN pagesel macro, which I used
> for a couple of years, until I noticed
> that MC had finally fixed it.
>
> When I  commented on it later on PICLIST, nobody had even noticed the
> error.
>
> BTW, I am unable to use anything later than 7.40 for my ICD2's on my
> XPs. Lord only knows what the problem is.
>
> --Bob
>

> I don't know either but that's the reason I still use 7.41 - not sure what
> is the diff between the 7.40 and this but it just works perfect for me.
> Sometimes I'm using the GPASM toolset as it generates a COD file that makes
> it possible to debug macros - even in MPSIM.
>
> But one thing i surely could not understand is that if the code was ok in
> simulator why or how was that behaving different in real world? I mean if
> that is a compiler bug? Would love to see the disassembled code compared to
> the working one.
>
> Tamas
>
>
>
> On 9/27/07, Bob Axtell <KILLspamengineerKILLspamcotse.net> wrote:
>  
>> Jinx wrote:
>>    
>>>> 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.
>>>>
>>>>        
>>> Several times I've noticed that MPASM doesn't pick up on typos.
>>> The most recent was when I used, from memory, the variable name
>>> op_stat. The compilation appeared to go OK. However, the real
>>> variable name I should have used was o_stat. Took lots of debugging
>>> to find that where op_stat had been used, there was no code made.
>>> For example movf op_stat,w was simply ignored. Replacing op_stat
>>> with o_stat fixed it all. Perhaps you should check carefully for typos
>>>
>>> (apologies if I've forgotten the original problem)
>>>
>>>
>>>      
>> The worst problem I noticed was old MPASM not handling "pagesel"
>> properly. That drove me crazy until
>> I finally found it. I simply created my OWN pagesel macro, which I used
>> for a couple of years, until I noticed
>> that MC had finally fixed it.
>>
>> When I  commented on it later on PICLIST, nobody had even noticed the
>> error.
>>
>> BTW, I am unable to use anything later than 7.40 for my ICD2's on my
>> XPs. Lord only knows what the problem is.
>>
>> --Bob
>>