Searching \ for '[PIC]: What have I done wrong?' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'What have I done wrong?'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: What have I done wrong?'
2002\02\01@075435 by Sean Alcorn - Avion Sydney

flavicon
face
Hi guys,

I am a newbie, but am starting to have some reasonable success.

To me, this code looks right, but it's just not working for me. Instead of
getting 6 loops of my code, I get heaps of them!

RADIX   DEC
;etc



MOVLW  6  ;We want to do this thing 6 times
MOVWF  COUNTER
LOOP
; Do some stuff
CALL   DELAY500; Delay 500ms
; Do some more stuff
CALL   DELAY500; Delay 500ms
DECFSZ   COUNTER, F
GOTO   LOOP

I eventually leave this loop, but after significantly more than 6 cycles.
What have I done wrong? It's like I have the wrong figure in the MOVLW   6
statement.

TYIA

Sean Alcorn

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\02\01@081553 by Drew Vassallo

picon face
>To me, this code looks right, but it's just not working for me. Instead of
>getting 6 loops of my code, I get heaps of them!

Your code in *this section* appears ok.  I would check your DELAY calls to
make sure that your COUNTER value isn't being changed somehow.  Perhaps you
have it mirrored with another register in another bank and you're not
switching banks properly, causing an errant change in your COUNTER register.
 Also check your ISRs for the same problems.

--Andrew

_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\02\01@081602 by Jinx

face picon face
> I eventually leave this loop, but after significantly more than
> 6 cycles.

How are you figuring it's more than 6 ? By measuring time ? Are
you sure the 500ms delay is correct ?

Have you tried running and monitoring it in MPLAB ? (with and
without the delay500 enabled)

Is  the RAM byte "Counter" being used in another part of the
program under a different name ? For example, have you
managed to assign the same address to two names ?

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\02\01@082148 by Peter Onion

flavicon
face
On 01-Feb-02 Sean Alcorn - Avion Sydney wrote:
> Hi guys,
>
> I am a newbie, but am starting to have some reasonable success.
>
> To me, this code looks right, but it's just not working for me. Instead of
> getting 6 loops of my code, I get heaps of them!

Sean,

The code you posted should work, but without details of the "do some stuff" and
the delay routine it is impossible to tell if there is something in there that
is corrupting the value in the loop counter.

I would guess that something is changing the value in COUNTER.

Maybe a bank switching problem, or maybe another variable asigned to the same
register file.

How do you asign variables to registers ?

Peter.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\02\01@083837 by Byron A Jeff

face picon face
On Fri, Feb 01, 2002 at 10:16:37PM +1100, Sean Alcorn - Avion Sydney wrote:
{Quote hidden}

One quick suggestions is to remove the contents of the loop and test
the functionality in isolation. The code looks correct at first glance. So
I'd bet that something in the "Do some stuff" or in the DELAY500 is
affecting counter.

Have you tested your code with a simulator?

BAJ

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\02\01@085245 by Sean Alcorn - Avion Sydney

flavicon
face
on 2/2/02 12:15 AM, Jinx at spam_OUTjoecolquittTakeThisOuTspamCLEAR.NET.NZ wrote:

>> I eventually leave this loop, but after significantly more than
>> 6 cycles.


> How are you figuring it's more than 6 ? By measuring time ?

I am toggling one of the Pins High and Low & driving an LED to test.


> Are you sure the 500ms delay is correct ?

Yes. Pretty close. I have used this code many times before, and I have the
LED to test (count)

> Have you tried running and monitoring it in MPLAB ? (with and
> without the delay500 enabled)

No. I have never had any success running in MPLAB! It takes far too long!!!

> Is  the RAM byte "Counter" being used in another part of the
> program under a different name ? For example, have you
> managed to assign the same address to two names ?

No. Definitely not!

So my RADIX   DEC and MOVLW 6 is correct?

Regards,

Sean

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\02\01@085511 by Sean Alcorn - Avion Sydney

flavicon
face
on 2/2/02 12:15 AM, Drew Vassallo at .....snurpleKILLspamspam@spam@HOTMAIL.COM wrote:

>> To me, this code looks right, but it's just not working for me. Instead of
>> getting 6 loops of my code, I get heaps of them!
>
> Your code in *this section* appears ok.  I would check your DELAY calls to
> make sure that your COUNTER value isn't being changed somehow.

Checked that.

> Perhaps you
> have it mirrored with another register in another bank and you're not
> switching banks properly, causing an errant change in your COUNTER register.
> Also check your ISRs for the same problems.

This is a 12C508. No banks to worry about or ISRs :-(

Regards,

Sean

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\02\01@095808 by Peter Onion

flavicon
face
On 01-Feb-02 Sean Alcorn - Avion Sydney wrote:
>
>> Have you tried running and monitoring it in MPLAB ? (with and
>> without the delay500 enabled)
>
> No. I have never had any success running in MPLAB! It takes far too long!!!
>

Take a hint Sean :-)  Finding this sort of bug is exactly the sort of thing
that simulators were designed for !

The reason it "It takes far too long!!!" in MPLAB is probably the same reason
it seems to go around the loop too many times on a real PIC.

Watch the value of COUNTER and see if it is being changed in unexpected places
in the code.

Peter.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\02\01@101410 by Scott Dattalo

face
flavicon
face
On Fri, 1 Feb 2002, Peter Onion wrote:

> On 01-Feb-02 Sean Alcorn - Avion Sydney wrote:
> >
> >> Have you tried running and monitoring it in MPLAB ? (with and
> >> without the delay500 enabled)
> >
> > No. I have never had any success running in MPLAB! It takes far too long!!!
> >
>
> Take a hint Sean :-)  Finding this sort of bug is exactly the sort of thing
> that simulators were designed for !
>
> The reason it "It takes far too long!!!" in MPLAB is probably the same reason
> it seems to go around the loop too many times on a real PIC.
>
> Watch the value of COUNTER and see if it is being changed in unexpected places
> in the code.

You may wish to investigate gpsim as your debugger. It can handle both of
the issues raised here: 1) Execution speed; gpsim runs faster than a real
PIC 2) Watching registers for you; You can set break points on register
reads or writes (you can even set break points on register bits).

http://www.dattalo.com/gnupic/gpsim.html

Scott

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\02\01@105254 by Carlos Ojea

flavicon
face
Is it possible to set break points on register reads or writes using Mplab ?

-----Original Message-----
From: Scott Dattalo <scottspamKILLspamDATTALO.COM>
To: .....PICLISTKILLspamspam.....MITVMA.MIT.EDU <EraseMEPICLISTspam_OUTspamTakeThisOuTMITVMA.MIT.EDU>
Date: viernes 1 de febrero de 2002 16:13
Subject: Re: [PIC]: What have I done wrong?


>On Fri, 1 Feb 2002, Peter Onion wrote:
>
>> On 01-Feb-02 Sean Alcorn - Avion Sydney wrote:
>> >
>> >> Have you tried running and monitoring it in MPLAB ? (with and
>> >> without the delay500 enabled)
>> >
>> > No. I have never had any success running in MPLAB! It takes far too
long!!!
>> >
>>
>> Take a hint Sean :-)  Finding this sort of bug is exactly the sort of
thing
>> that simulators were designed for !
>>
>> The reason it "It takes far too long!!!" in MPLAB is probably the same
reason
>> it seems to go around the loop too many times on a real PIC.
>>
>> Watch the value of COUNTER and see if it is being changed in unexpected
places
{Quote hidden}

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\02\01@154909 by Jinx

face picon face
> > Have you tried running and monitoring it in MPLAB ? (with
> > and without the delay500 enabled)
>
> No. I have never had any success running in MPLAB! It takes
> far too long!!!

That may be false economy. I had something similar to this a
while ago and struggled long and hard to find the problem before
I gave in and ran it through MPLAB. Yes, it did take a while, but
the cause of the problem was found very quickly. One simple
conditional break-point and it was all over, I kicked myself at
something that had been staring me in the face all day and
moved on. It sounds like a cheap platitude, but it is never a
good idea to check your own work. Short of posting the entire
code for us to look at, MPLAB is a good sniffer dog

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\02\01@183057 by Sean Alcorn - Avion Sydney

flavicon
face
on 2/2/02 7:48 AM, Jinx at joecolquittspamspam_OUTCLEAR.NET.NZ wrote:

Hi Joe,

> That may be false economy. I had something similar to this a
> while ago and struggled long and hard to find the problem before
> I gave in and ran it through MPLAB. Yes, it did take a while, but
> the cause of the problem was found very quickly.

I thought it was just me or my computer! Surely it could be re-written to
run faster than it does. I bought a PIC Tutor package and it came with a
little simulator program. It has arrays of "LEDs" on the screen to indicate
pins, registers etc. and it runs in real time! The only downside is that you
have to write the code inside this little app and it is only for the
PIC16F84, but surely Microchip could do something like this.

One simple
> conditional break-point and it was all over, I kicked myself at
> something that had been staring me in the face all day and
> moved on. It sounds like a cheap platitude, but it is never a
> good idea to check your own work. Short of posting the entire
> code for us to look at, MPLAB is a good sniffer dog

Yeah, fair enough. I do not mind posting all of my code, but my code gets
spat out of my compiler - and before anybody says "Why don't you write it
yourself" - I am now writing about 90% of simple programs myself. However, I
write them *inside* the compiler as an assembly instruction. Then when I
'compile' my code, the compiler kindly strips away all my comments. :-(

So, I do not like to post my complete, uncommented code. Here it is as
follows with a few quick comments addaed. Also the delay routine used to be
at the end. I have moved it to the beginning of the code, but no other
changes have been made.


    LIST P= 12C508A
    INCLUDE "P12C508A.INC"
    RADIX DEC
    ORG  0X1
AUX1_L EQU  0X7
AUX1_H EQU  0X8
AUX2_L EQU  0X9
AUX2_H EQU  0XA
AUX EQU  0XB
S0 EQU  0XC
COUNTB EQU  0XD
COUNT_H EQU  0XE
COUNT_L EQU  0XF
    __CONFIG   _CP_OFF & _WDT_ON & _MCLRE_OFF & _INTRC_OSC
    MOVWF  OSCCAL
    GOTO   STARTHERE
    ORG  0X40
DELAY500
    ; CREATE A DELAY OF 500MS
    MOVLW  9;*
    MOVWF  AUX2_L
DELAYLAB31
    MOVLW  169;*
    MOVWF  AUX1_H;*
DELAYLAB21
    MOVLW  81;*
    MOVWF  AUX1_L;*
DELAYLAB11
    CLRWDT
    DECFSZ AUX1_L, F;*
    GOTO   DELAYLAB11
    CLRWDT
    DECFSZ AUX1_H, F;*
    GOTO   DELAYLAB21
    CLRWDT
    DECFSZ AUX2_L, F;*
    GOTO   DELAYLAB31
    RETLW  0
STARTHERE
    MOVLW  B'000000'
    TRIS   GPIO
STAGE1
    MOVLW  6; I want a delay of 6 seconds
    MOVWF  COUNTB
STAGE1_LEDON
    MOVLW  B'000011'
    MOVWF  GPIO
    CALL   DELAY500
STAGE1_LEDOFF
    MOVLW  B'100011'
    MOVWF  GPIO
    CALL   DELAY500
    DECFSZ COUNTB, F
    GOTO   STAGE1_LEDON
IDLE1; just a 500ms delay
    MOVLW  B'100001'
    MOVWF  GPIO
    CALL   DELAY500
STAGE2
    MOVLW  10; I want a delay of 5 seconds
    MOVWF  COUNTB
STAGE2_2
    MOVLW  B'000101'
    MOVWF  GPIO
    CALL   DELAY500
    DECFSZ COUNTB, F
    GOTO   STAGE2_2
IDLE2
    MOVLW  20; I want a delay of 10 seconds here with NOTHING happening
    MOVWF  COUNTB
IDLE3
    MOVLW  B'100000'
    MOVWF  GPIO
    CALL   DELAY500
    DECFSZ COUNTB, F
    GOTO   IDLE3
    GOTO   STAGE1
    END

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\02\01@183704 by Sean Alcorn - Avion Sydney

flavicon
face
on 2/2/02 2:01 AM, Peter Onion at @spam@ponionKILLspamspamSRD.BT.CO.UK wrote:

Peter,

> Take a hint Sean :-)  Finding this sort of bug is exactly the sort of thing
> that simulators were designed for !

Yes. I agree. But the particular MPLAB simulator is all but useless to me.

> The reason it "It takes far too long!!!" in MPLAB is probably the same reason
> it seems to go around the loop too many times on a real PIC.

No. Not so. It takes minutes to complete a single 500mS delay!


> Watch the value of COUNTER and see if it is being changed in unexpected places
> in the code.

See my code just posted in response to Jo (jinx). It's real simple. The LED
on GP5 (Pin 6) is toggling perfectly. All I do is count them and I lose
count! :-) A lot more than 6.

Regards,

Sean

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\02\01@184120 by Andrew Warren

flavicon
face
Sean Alcorn - Avion Sydney <KILLspamPICLISTKILLspamspammitvma.mit.edu> wrote:

> [MPLAB] takes minutes to complete a single 500mS delay!

   So make a "debug" version of your code that replaces the three
   constants in your delay routine with 0x01.

   -Andy

=== Andrew Warren -- RemoveMEaiwTakeThisOuTspamcypress.com
=== Principal Design Engineer
=== Cypress Semiconductor Corporation
===
=== Opinions expressed above do not
=== necessarily represent those of
=== Cypress Semiconductor Corporation

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\02\01@194418 by Jinx

face picon face
Are you using WDT ? You could lose the CLRWDTs otherwise

>      __CONFIG  & _WDT_ON &

My quick back-of-envelope calcs suggest the DELAY500
routine is taking almost 8,000,000 cycles. To be done in 500ms
that would imply a 64MHz crystal  (64,000,000/4/2)

(Ignoring 2-cycle DECFSZ)

(4 x 9) x (4 x 169) x (4 x 81) = 7,884,864

At 4Mhz (1us instruction time) this would take 8 seconds

Assuming I'm right (lot on today, I feel like an octopus
playing the drums), and your 500ms isn't critical, use
a WDT interrupt for timing (would take about 28 at 18ms
each), or just a two-level nest. Get the internal loop to
around 2000 cycles with NOPs and a 0-255 count for the
external, if you're running at 4MHz. If you want exactly
500ms you'll have to get the calculator out and take a
look at the timing routine suggestions at http://www.piclist.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\02\01@222412 by Sean Alcorn - Avion Sydney

flavicon
face
on 2/2/02 11:41 AM, Jinx at spamBeGonejoecolquittspamBeGonespamCLEAR.NET.NZ wrote:

Hi Joe,

> Are you using WDT ? You could lose the CLRWDTs otherwise

Yes. Am using the WDT.

> My quick back-of-envelope calcs suggest the DELAY500
> routine is taking almost 8,000,000 cycles. To be done in 500ms
> that would imply a 64MHz crystal  (64,000,000/4/2)

> (Ignoring 2-cycle DECFSZ)
>
> (4 x 9) x (4 x 169) x (4 x 81) = 7,884,864
>
> At 4Mhz (1us instruction time) this would take 8 seconds

Then you will understand my frustration. If what you have calculated is
true,  then it does not explain my (almost) perfect Flash rate of 1Hz on GP5
(Pin7) which is achieved by two delay calls.

This same delay routine is working flawlessly in other applications.

I simply can not see how there can be anything wrong with an already proven
delay routine and one that seems to be working in this application.

I am geting a CORRECT flash rate of approximately 1 Hz on GP5, and I am
simply trying to count 6 cycles of that.

> Assuming I'm right (lot on today, I feel like an octopus
> playing the drums), and your 500ms isn't critical, use
> a WDT interrupt for timing (would take about 28 at 18ms
> each), or just a two-level nest. Get the internal loop to
> around 2000 cycles with NOPs and a 0-255 count for the
> external, if you're running at 4MHz. If you want exactly
> 500ms you'll have to get the calculator out and take a
> look at the timing routine suggestions at http://www.piclist.com

Sorry. A bit much in the above for a newbie. But I like the suggestion of
using a WDT for timing. How would one do this? Isn't a WDT interrupt just
like a reset with the exception of a couple of flags?

Regards,

Sean

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\02\01@225801 by Jinx

face picon face
> > At 4Mhz (1us instruction time) this would take 8 seconds
>
> Then you will understand my frustration. If what you have
> calculated is true,  then it does not explain my (almost) perfect
> Flash rate of 1Hz on GP5 (Pin7) which is achieved by two
> delay calls.

I hope it is true, I'm not firing on all cylinders today (watched the
ODI cricket until 3am), but no one's jumped in to disagree

I don't understand how you've got your flash rate either, unless
it's by some quirky accident of timing

> This same delay routine is working flawlessly in other applications.

Hmmm

> I simply can not see how there can be anything wrong with an
> already proven delay routine and one that seems to be working
> in this application.

Unless someone says my calcs are wrong, I don't know how
to explain that

> I am geting a CORRECT flash rate of approximately 1 Hz on
> GP5, and I am simply trying to count 6 cycles of that.

Or that

{Quote hidden}

What I was saying is that you needn't have 3 routines nested
3-deep. You could do it with two (or even just one if you were
using a micro that had an interrupting timer). It's just a question
of taking the number of cycles in the delay you want and finding
factors for it (then smoothing over the cracks if you want very
accurate repeatability)

> But I like the suggestion of using a WDT for timing. How would
> one do this? Isn't a WDT interrupt just like a reset with the
> exception of a couple of flags?

There is a special use for WDT that you may be able to use.
You put the micro to SLEEP. When the WDT times out, program
flow continues after the SLEEP instruction, rather than a reset

It's quite simple to do, and is well-documented with no gotchas
that I recall

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\02\04@040105 by Alan B. Pearce

face picon face
>This same delay routine is working flawlessly in other applications.
>
>I simply can not see how there can be anything wrong with an already proven
>delay routine and one that seems to be working in this application.

This then implies that somewhere else in your code, there is an access to
the counter variable that should not be there. Try doing something as simple
as using your editor to search for all instances of the variable name. You
may be surprised where it pops up :)

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email TakeThisOuTlistservEraseMEspamspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body


More... (looser matching)
- Last day of these posts
- In 2002 , 2003 only
- Today
- New search...