Truncated match.
PICList
Thread
'PIC 16C84 fails to execute decfsz'
1999\01\04@102132
by
Stefan Sczekalla-Waldschmidt
|
Hi,
Yesterday I found a very odd behaviour using a PIC16C84.
While debugging a program which runs fine using MP-Lab simulator,
the same program doesn4t seemed to work within the real PIC.
Well normaly nothing new, but I checked everything twice. So I started
to add some LED4s to get a glue about the portions of software executed.
After fixing some minor bugs, I could see the IRQ flashing a certain
led,
and see the program running through the initialisation, till the
Main-Program.
There it seemed to get somewhow screwed-up. by moving the point where
one of
my LED4s got enlightet, I could break the point of malfunction down.
Code was as below:
wait: movlw 0x30 ;
movwf dwncntr
bsf PORTB, 3 ; set LED to on executed as possible
decfsz dwncntr, F
goto $-1
bsf PORTB, 4 ; set LED to on NEVER EXECUTET !!!!!!!
return
As I found the decfsz op must cause this failure. Fortunately I had some
16F84 on "Stock" so I tryed one of them in opposite to the previousely
used 16C84.
Well - they worked - the above with "NEVER EXECUTED" marked instruction
was executed,
the Led got switched on as expected.
Now I4m wondering if the batch of 16C84 is errenous, my programmer is
unreliable ...
Because I tryed to be aware of setting PCLATH according to the
requirements, I think
I can exclude the possibility of jump into the nirwana, I also checked
the absolute listing.
Any comments, suggestions ??
Best wishes to the new jear, much success with your projects.
Kind regards
Stefan
1999\01\04@110400
by
Morgan Olsson
|
Only thing i can think of right now,
is the watchdog triggering while counting down dwncounter.
And the watchdog have varying time between chip individuals.
Is it enabled? Any other interrupt enabled?
Stable supply? Tested other supply?
Other voltages maybe work if slightly bad chip or not fully programmed.
Oh, is the PORTB correctly set up?
Can you light the led using another routine?
{Quote hidden}>Code was as below:
>
>wait: movlw 0x30 ;
> movwf dwncntr
>
> bsf PORTB, 3 ; set LED to on executed as possible
>
> decfsz dwncntr, F
> goto $-1
>
> bsf PORTB, 4 ; set LED to on NEVER EXECUTET !!!!!!!
> return
>
>As I found the decfsz op must cause this failure. Fortunately I had some
>16F84 on "Stock" so I tryed one of them in opposite to the previousely
>used 16C84.
>Well - they worked - the above with "NEVER EXECUTED" marked instruction
>was executed,
>the Led got switched on as expected.
>
>Now I4m wondering if the batch of 16C84 is errenous, my programmer is
>unreliable ...
Have you tried several C84?
(probably slightly varying watchdog timeout)
Isolate test, no goto, something like this: (no dealy loop, just test decfsz)
wait: movlw 2
movwf dwncntr
decfsz dwncntr, F
bsf PORTB, 3 ;Shall light (dwncntr not reaching zero)
bsf PORTB, 4 ;Will light unless in nirvana mode...
decfsz dwncntr, F
bsf PORTB, 5 ;Shall not light (dwncntr reaching zero)
bsf PORTB, 6 ;Will light unless in nirvana mode...
>Because I tryed to be aware of setting PCLATH according to the
>requirements, I think
>I can exclude the possibility of jump into the nirwana, I also checked
>the absolute listing.
Er.. Do 16C84 need setting the PCLATH before GOTO?
>
>Any comments, suggestions ??
>
>Best wishes to the new jear, much success with your projects.
>
>Kind regards
>
> Stefan
>
>
Morgan Olsson ph +46(0)414 70741
MORGANS REGLERTEKNIK fax +46(0)414 70331
H€LLEKS (in A-Z letters: "HALLEKAS")
SE-277 35 KIVIK, SWEDEN spam_OUTmrtTakeThisOuT
iname.com
___________________________________________________________
1999\01\04@113241
by
Stefan Sczekalla-Waldschmidt
|
Hi Morgan
Morgan Olsson wrote:
>
> Only thing i can think of right now,
> is the watchdog triggering while counting down dwncounter.
> And the watchdog have varying time between chip individuals.
> Is it enabled?
for sure, I had the watchdog disabled.
> Any other interrupt enabled?
Yes but it worked es expected, given a periodical output I4ve seen on my
scope.
timing also as expected.
> Stable supply?
Hope so, commercial 19" Power-Supply with 5V and 12V output.
> Tested other supply?
No
> Other voltages maybe work if slightly bad chip or not fully programmed.
Tomething I could try again, just to verify the failure ...
Hm... the programmer did the verify correct, but I think it didn4t test
at more then
one voltage.
>
> Oh, is the PORTB correctly set up?
> Can you light the led using another routine?
yes, also using a 16F84 from a different batch than the 16C84 gives no
errors.
> Have you tried several C84?
Yes, all the same batch - all behaves odd.
> (probably slightly varying watchdog timeout)
>
no watchdog used as stated above.
{Quote hidden}> Isolate test, no goto, something like this: (no dealy loop, just test decfsz)
> wait: movlw 2
> movwf dwncntr
>
> decfsz dwncntr, F
> bsf PORTB, 3 ;Shall light (dwncntr not reaching zero)
> bsf PORTB, 4 ;Will light unless in nirvana mode...
>
> decfsz dwncntr, F
> bsf PORTB, 5 ;Shall not light (dwncntr reaching zero)
> bsf PORTB, 6 ;Will light unless in nirvana mode...
When having some more time I will test the erroneous assumed chips again
with
the different supply-voltages and the code above.
>
> >Because I tryed to be aware of setting PCLATH according to the
> >requirements, I think
> >I can exclude the possibility of jump into the nirwana, I also checked
> >the absolute listing.
>
> Er.. Do 16C84 need setting the PCLATH before GOTO?
normaly no, because the address range of goto is sufficient for the
16X84. But just
to be sure.
Kind regards
Stefan
1999\01\04@123421
by
Dmitry Kiryashov
Hello Stefan.
decfsz command do work nicely in PIC16F84. I've no trouble with
this cmd. Try to seek reason in other place - for instance F84
& C84 have a different fuses data, also check the WDT disabling.
Make sure that all vars located in correct RAM places, something
else...
WBR Dmitry.
{Quote hidden}> Code was as below:
>
> wait: movlw 0x30 ;
> movwf dwncntr
>
> bsf PORTB, 3 ; set LED to on executed as possible
>
> decfsz dwncntr, F
> goto $-1
>
> bsf PORTB, 4 ; set LED to on NEVER EXECUTET !!!!!!!
> return
1999\01\05@111431
by
Peter L. Peres
> decfsz dwncntr, F
> goto $-1
imho, get rid of the '$-1' and use a label, as in:
dec_dwnctr:
decfsz dwnctr, F
goto dec_dwnctr
I assume that you have checked all the other things, such as the Watchdog
etc.
$0.02
Peter
1999\01\05@133557
by
Mark Willis
|
Um, I don't *ever* use those "goto $-1" type jumps, so I may be wrong
here, but: Am I remembering correctly that a goto $-1 will decrement
the instruction counter (which has already been incremented) so this
will loop in place? Or am I hallucinating here? (Could be thinking of
a different processor; THAT is why I always use labels, having used
Z80's, 80x86's, 8008's, Pics, and a few MOT parts, you get really tired
of shooting your feet to swiss cheese by this sort of thing, as well as
having to go re-code all the relative jumps each time the code's desired
behavior changes!)
Probably sticking my foot in my mouth, so I'll go wash my foot now,
need some chocolate soap here! <G> But, I thought I'd ask (This sort of
thing is exactly why I use labels not relative jumps & let the assembler
(or translator) handle the translations for me <G>
Need to get recovered from having crashed the PicStart Plus machine to
toast so I can get back to running code here <G>
Mark, .....mwillisKILLspam
@spam@nwlink.com
Peter L. Peres wrote:
{Quote hidden}>
> > decfsz dwncntr, F
> > goto $-1
>
> imho, get rid of the '$-1' and use a label, as in:
>
> dec_dwnctr:
> decfsz dwnctr, F
> goto dec_dwnctr
>
> I assume that you have checked all the other things, such as the Watchdog
> etc.
>
> $0.02
>
> Peter
1999\01\05@152237
by
Adam Bryant
|
Mark,
I do use relative jumps in many situations. With the PIC you can think of
the "$" being evaluated BEFORE the instruction counter is incremented. So
$-1 means "jump back to the previous instruction", $ means "jump to this
instruction" (an endless loop), and $+1 means "jump to the next
instruction" (I use this one all the time in timing loops as it is a 1
instruction method to get a 2 cycle delay). I use relative instructions in
macros and in loops where I don't want to clutter up the code with an extra
label. But I do limit the use of relative jumps to places where I am
jumping a short distance (usually < 10 instructions).
You are right, you do need to be careful if you change the code to insure
that the relative jump is still correct. But using them for small jumps in
non-changing segments of code is pretty safe.
Adam
mwillis
KILLspamNWLINK.COM on 01/05/99 11:36:04 AM
Please respond to .....PICLISTKILLspam
.....MITVMA.MIT.EDU
To: EraseMEPICLISTspam_OUT
TakeThisOuTMITVMA.MIT.EDU
cc: (bcc: Adam Bryant/PEAK/MOORE)
Subject: Re: PIC 16C84 fails to execute decfsz
Um, I don't *ever* use those "goto $-1" type jumps, so I may be wrong
here, but: Am I remembering correctly that a goto $-1 will decrement
the instruction counter (which has already been incremented) so this
will loop in place? Or am I hallucinating here? (Could be thinking of
a different processor; THAT is why I always use labels, having used
Z80's, 80x86's, 8008's, Pics, and a few MOT parts, you get really tired
of shooting your feet to swiss cheese by this sort of thing, as well as
having to go re-code all the relative jumps each time the code's desired
behavior changes!)
Probably sticking my foot in my mouth, so I'll go wash my foot now,
need some chocolate soap here! <G> But, I thought I'd ask (This sort of
thing is exactly why I use labels not relative jumps & let the assembler
(or translator) handle the translations for me <G>
Need to get recovered from having crashed the PicStart Plus machine to
toast so I can get back to running code here <G>
Mark, mwillis
spam_OUTnwlink.com
Peter L. Peres wrote:
{Quote hidden}>
> > decfsz dwncntr, F
> > goto $-1
>
> imho, get rid of the '$-1' and use a label, as in:
>
> dec_dwnctr:
> decfsz dwnctr, F
> goto dec_dwnctr
>
> I assume that you have checked all the other things, such as the Watchdog
> etc.
>
> $0.02
>
> Peter
1999\01\06@041110
by
Stefan Sczekalla-Waldschmidt
Hi Peter,
"Peter L. Peres" wrote:
>
> > decfsz dwncntr, F
> > goto $-1
>
> imho, get rid of the '$-1' and use a label, as in:
>
> dec_dwnctr:
> decfsz dwnctr, F
> goto dec_dwnctr
Tried this too - without success ...
>
> I assume that you have checked all the other things, such as the Watchdog
> etc.
Yes. btw - same code with different batch of 16X84 runs definitely.
>
> $0.02
>
> Peter
While I didnt tested I think it may have to do something with a odd
sensibility
to the supplied voltage.
1999\01\06@043414
by
Stefan Sczekalla-Waldschmidt
|
Hi,
Mark Willis wrote:
>
> Um, I don't *ever* use those "goto $-1" type jumps, so I may be wrong
> here, but: Am I remembering correctly that a goto $-1 will decrement
> the instruction counter (which has already been incremented) so this
> will loop in place?
Also Peter mentioned this - I thought - and think - the reference is the
current PC -
well because of not trusting the assembler I took a look into th
absolute listing.
The Addres in the Adresspart of the GOTO was correctely pointing to the
address
before - the address of the decfsz.
> Or am I hallucinating here? (Could be thinking of
> a different processor; THAT is why I always use labels, having used
> Z80's, 80x86's, 8008's, Pics, and a few MOT parts, you get really tired
> of shooting your feet to swiss cheese by this sort of thing, as well as
> having to go re-code all the relative jumps each time the code's desired
> behavior changes!)
Well your somewhat right, I use this kind "$-+X" only for very short
jumps in
compare-like sequences or loops like the used one. A "benefit" of this
kind of
notation is, that it gives a clearer reference ( kind of tight binding )
to it4s
( in this case close ) context.
> Probably sticking my foot in my mouth, so I'll go wash my foot now,
> need some chocolate soap here! <G>
nice saying :-) would like to be so flexible :-)
> But, I thought I'd ask (This sort of
> thing is exactly why I use labels not relative jumps & let the assembler
> (or translator) handle the translations for me <G>
>
> Need to get recovered from having crashed the PicStart Plus machine to
> toast so I can get back to running code here <G>
You "toasted" your Picstart-Plus ??? Well - Here we sometimes say "ein
Programm in ein Eprom brennen" (burning a program into a EPROM) but I
never thought about "toasing" a programm into a chip <G>
Kind regards
Stefan
@spam@sswKILLspam
oikossw.de
1999\01\06@043747
by
Stefan Sczekalla-Waldschmidt
|
Adam Bryant wrote:
>
> Mark,
> I do use relative jumps in many situations. With the PIC you can think of
> the "$" being evaluated BEFORE the instruction counter is incremented. So
> $-1 means "jump back to the previous instruction", $ means "jump to this
> instruction" (an endless loop), and $+1 means "jump to the next
> instruction" (I use this one all the time in timing loops as it is a 1
> instruction method to get a 2 cycle delay).
> I use relative instructions in
> macros and in loops where I don't want to clutter up the code with an extra
> label. (#)
> But I do limit the use of relative jumps to places where I am
> jumping a short distance (usually < 10 instructions).
>
> You are right, you do need to be careful if you change the code to insure
> that the relative jump is still correct. But using them for small jumps in
> non-changing segments of code is pretty safe.
Yes, thats the way I use it.
(#): another benefit I forgot to mention - I think it was my original
idea for
using this notation.
Kind regards
Stefan
1999\01\06@053317
by
Mark Willis
Stefan Sczekalla-Waldschmidt wrote:
>
> Hi,
>
> Mark Willis wrote:
> > <Snipped down>
>
> You "toasted" your Picstart-Plus ??? Well - Here we sometimes say "ein
> Programm in ein Eprom brennen" (burning a program into a EPROM) but I
> never thought about "toasing" a programm into a chip <G>
>
> Kind regards
>
> Stefan
> KILLspamsswKILLspam
oikossw.de
Nope, the machine had a HDD formatting problem (My mistake, for once)
and I need to completely re-install Windows & MPLab & all as the drive's
blank now (It was easier to just re-start from scratch.) Gotta be
careful when using some tools as the wrong keystrokes will happily nuke
a drives' contents, inconveniencing us a LOT! What I get for trying to
do Tech work at 4 AM, when I have time but no brainpower left <G>
Mark, RemoveMEmwillisTakeThisOuT
nwlink.com
1999\01\06@053727
by
Morgan Olsson
|
At 13:16 1999-01-05 -0700, you wrote:
>Mark,
>I do use relative jumps in many situations. With the PIC you can think of
>the "$" being evaluated BEFORE the instruction counter is incremented. So
>$-1 means "jump back to the previous instruction", $ means "jump to this
>instruction" (an endless loop), and $+1 means "jump to the next
>instruction" (I use this one all the time in timing loops as it is a 1
>instruction method to get a 2 cycle delay). I use relative instructions in
>macros and in loops where I don't want to clutter up the code with an extra
>label. But I do limit the use of relative jumps to places where I am
>jumping a short distance (usually < 10 instructions).
>
>You are right, you do need to be careful if you change the code to insure
>that the relative jump is still correct. But using them for small jumps in
>non-changing segments of code is pretty safe.
>
>Adam
>
Nonono!
** There is no relative jump instructions _in_the_PIC_ **
The compiler converts them to absolute,
(and OBS: in that code page), however you express the adress.
Using relative _notation_ makes the code clearer for short jumps, and
minimizes the number of labels. Not using labels can however make
debugging slightly more difficult.
/Morgan
Morgan Olsson ph +46(0)414 70741
MORGANS REGLERTEKNIK fax +46(0)414 70331
H€LLEKS (in A-Z letters: "HALLEKAS")
SE-277 35 KIVIK, SWEDEN spamBeGonemrtspamBeGone
iname.com
___________________________________________________________
1999\01\06@073857
by
paulb
|
Stefan Sczekalla-Waldschmidt wrote:
> Yes. btw - same code with different batch of 16X84 runs definitely.
Hey, look, let«s face it, he has tried exactly the same code and
*everything else* on at least two production batches of 16C84s and on
16F84s. *One* production batch is faulty. From what I read, it would
be nothing like the first time this happened.
But that«s the end of the story, faulty batch; don«t use them, at
least with this program. For a program they execute alright, use them
and get them out the door! ;-)
So you want to know *why* they are faulty? Well, my hypothesis is that
there is a multiplexer in the pipleine which must respond appropriately
in one fashion to the "bit test and skip" instruction, and in another
to the "goto". Both these affect the Program Counter in some way or
another, so it seems plausible that the juxtaposition of the
instructions stresses a critical timing issue in this multiplexer and in
these chips - it just doesn«t make it.
Another way of looking at it, the "Skip if" instruction has to "turn
off" the following instruction, probably by purging or halting the
pipeline. The "Goto" does something similar as it also takes two
cycles. Maybe the gates for these instructions are interconnected by
accident in this mask set.
--
Cheers,
Paul B.
1999\01\06@121846
by
Peter L. Peres
|
Hello Stefan,
On Wed, 6 Jan 1999, Stefan Sczekalla-Waldschmidt wrote:
> The Addres in the Adresspart of the GOTO was correctely pointing to the
> address before - the address of the decfsz.
imho, to be sure, look at the offset of the goto instruction in the .LST
file and extract that byte from the object file, and compare to the binary
instruction code in the Mchip catalog. If the code is correct (should jump
to that location -1) then there is something funny going on in your chip,
else it is the compiler.
If you get paranoid about this, read the code back from a programmed chip,
and get the byte from there for examination.
> You "toasted" your Picstart-Plus ??? Well - Here we sometimes say "ein
> Programm in ein Eprom brennen" (burning a program into a EPROM) but I
> never thought about "toasing" a programm into a chip <G>
Toasting a machine is a little bit worse than burning an EPROM afaik. It
means that it needs to be replaced ;) The whole of it ;) Steart with the
OS Mark ;) ;)
good luck,
Peter
More... (looser matching)
- Last day of these posts
- In 1999
, 2000 only
- Today
- New search...