Searching \ for '[PIC] First shot errors' 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: 'First shot errors'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] First shot errors'
2007\03\15@103218 by Rikard Bosnjakovic

picon face
part 1 1229 bytes content-type:text/plain; charset=ISO-8859-1; format=flowed (decoded 7bit)

So, finally I was able to use a programmer and a chip (16F628a to be
exact). Feeling the rush of excite, I immediately hacked together a
"running light"-test in MPLAB, just for the sake of trying the
microcontroller out. It worked the first time, I was amazed!

But, since this opposed to using MPLAB is reality, the happiness was
not for long; because there were some errors. The lights (LEDs) were
running, sure, but the supposed delay of 5 seconds between each light
is wrong; the lights are in a sort of rush hour and then stops. I
don't know if this occurs codewise or breadboard-wise, but probably
the latter, because if i touch the board or some pins, the lights
start again. Sometimes they run, sometimes only one is lit, etc. Some
oscillation perhaps? Nothing except the PIC and 4 LEDs are connected
on the board.

I also thought it might had to do with the lack of crystal (I used the
internal oscillator), but alas; adding a 14MHz-crystal and proper caps
did not solve the problem. The lights surely runs even faster, but the
problem still occurs.

I'm attaching my code that I used for testing, feel free to take a
peek and berate me to better knowledge.


--
- Rikard.


part 2 1454 bytes content-type:text/plain; name="ledtest.asm"
(decoded base64)

       list      p=16f628A           ; list directive to define processor
       #include       ; processor specific variable definitions

   __CONFIG _CP_OFF & _WDT_OFF & _BODEN_OFF & _PWRTE_ON & _INTOSC_OSC_NOCLKOUT &  _LVP_OFF


korb        code     0x000             ; processor reset vector
       goto    main              ; go to beginning of program

start    code

; this delay-routine was borrowed from "The quintessial PIC microcontroller" by S. Katzen
COUNT_H        res 1
COUNT_L        res 1
N                equ        .130

delay100
       movlw        N
       movwf        COUNT_H
       clrf        COUNT_L
d_loop
       decfsz        COUNT_L, f
        goto        d_loop
       decfsz        COUNT_H, f
        goto        d_loop
finito
       return

; start here
main
       banksel        TRISB
       clrf        TRISB                                ; set all outputs
       banksel PORTB
       clrf        PORTB

   banksel CMCON               ; go back to bank0
   movlw   b'00000111'         ; turn off the comparator function for PORTA
   movwf   CMCON

loop
       movlw        .1                ; set RB0
       movwf        PORTB

       movlw   .50                ; delay 50 * 0.1 = 5 secs (supposedly)
       call    delay100


       rlf     PORTB           ; move to RB1

       movlw   .50
       call    delay100

       rlf     PORTB           ; move to RB2

       movlw   .50
       call    delay100

       rlf     PORTB           ; move to RB3

       movlw   .50
       call    delay100

       goto    loop


       END                       ; directive 'end of program'

part 3 35 bytes content-type:text/plain; charset="us-ascii"
(decoded 7bit)

2007\03\15@105846 by Alan B. Pearce

face picon face
<I'm attaching my code that I used for testing, feel free
>to take a peek and berate me to better knowledge.

OK, first question - what have you done with the MCLR pin. It is not
disabled that I can see, and you haven't mentioned tying it to Vcc using a
resistor.

2007\03\15@111946 by George Richards

flavicon
face
The original delay loop is for a 4MHz oscillator. For creating timing loops,
I use a neat little program called picloops (just google for it).

The erratic operation sounds like a mclr issue.

{Original Message removed}

2007\03\15@112600 by Howard Winter

face
flavicon
picon face
Rikard,

On Thu, 15 Mar 2007 15:32:10 +0100, Rikard Bosnjakovic wrote:

>...
> Nothing except the PIC and 4 LEDs are connected on the board.

There really ought to be some resistors to current-limit the LEDs - although they will survive for a while if the on-time is short, giving them time to
cool between flashes, but it's not a good idea.  When moderately overheated LEDs tend to just not light up - and they will recover after letting them
cool again, but gross overheating will destroy them.

>...
> adding a 14MHz-crystal and proper caps did not solve the problem.

>From memory, I think that's faster than a 628A will take - I think the limit is 10MHz, but I haven't checked the datasheet and I may be wrong.

Cheers,


Howard Winter
St.Albans, England


2007\03\15@113102 by Rikard Bosnjakovic

picon face
On 3/15/07, George Richards <spam_OUTgrichardsTakeThisOuTspammchsi.com> wrote:

> The original delay loop is for a 4MHz oscillator.

According to the datasheet, when i set the PIC to use the internal
clock then it'll be 4MHz. Do I still need to use an external 4MHz
oscillator?


--
- Rikard.

2007\03\15@113450 by Howard Winter

face
flavicon
picon face
Rikard,

Perhaps I should have looked at the code before sending my last!  :-)

In several places you do this:

       movlw   .50                ; delay 50 * 0.1 = 5 secs (supposedly)
       call    delay100

but the delay routine starts:

delay100
       movlw        N

so whatever you were intending the 50 to do, it's being overwritten by N almost immediately afterwards, and I don't see anywhere that the 50
repeats would be handled even if it wasn't, so if your delay routine itself is correct you'll be getting 0.1s delays, not 5s.

Cheers,


Howard Winter
St.Albans, England


2007\03\15@113852 by Andrei Yurkevich

picon face

On Mar 15, 2007, at 6:19 PM, George Richards wrote:

> The original delay loop is for a 4MHz oscillator. For creating  
> timing loops,
> I use a neat little program called picloops (just google for it).
>
> The erratic operation sounds like a mclr issue.

Also, in most cases it helps to pull down the unused IO-pins on the  
microcontroller - tie them to GND with 10K~47K resistors. At least,  
that helped me to solve the same issue with 16F877. Another problem  
may be with your power supply - putting a 100n cap between Vcc and  
Vdd may help - at least, it never hurts.

cheers,
Andrei

2007\03\15@114850 by Dave Wheeler

flavicon
face


----------------Big Snip------------------

Hi Rikard,

On top of what has already been said.

In your code you have

       movlw   .50                ; delay 50 * 0.1 = 5 secs (supposedly)
       call    delay100

but when you look at your delay100 routine it does:



delay100
       movlw        N
       movwf        COUNT_H
       clrf        COUNT_L

As N has a value of 130 (dec) assigned to it, the delay should (based on the correct oscillator frequency) actually give you 130*0.1 = 13 seconds. To use the value passed to the routine in 'W' just remove the movlw N from the start.

However, doing some quick maths, the loop runs for much less time than you think, I recon without doing the sums it is more like 0.03 seconds. You can use the stopwatch in MPLAB to confirm.

Welcome to the wonderful world of PIC's

Cheers,

Dave

       


{Quote hidden}

2007\03\15@120356 by Michael Rigby-Jones

picon face
{Quote hidden}

By my calculations at count of 130 gives just over 100,000 cycle delay, which is the required 0.1 seconds with a 4MHz clock.

The OP needs to wrap another loop around the delay that uses the value held in W to control the number of iterations of the 0.1 second delay.

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2007\03\15@120845 by Rikard Bosnjakovic

picon face
On 3/15/07, Alan B. Pearce <.....A.B.PearceKILLspamspam.....rl.ac.uk> wrote:

> OK, first question - what have you done with the MCLR pin. It is not
> disabled that I can see, and you haven't mentioned tying it to Vcc using a
> resistor.

I have not disabled it and I'm not touching it. I'm not perfectly
clear about what the datasheet tells me about that pin, so it felt
better to not touch it:

"Master clear. When configured as MCLR, this
pin is an active low Reset to the device.
Voltage on MCLR/VPP must not exceed VDD
during normal device operation"

Now there's Vpp too, as if Vdd/Vss didn't confuse me enough. So,
disable MCLR in the config word and tie the pin to Vcc/Vdd via a
resistor, is that the way to go?


--
- Rikard.

2007\03\15@121910 by Michael Rigby-Jones

picon face


{Quote hidden}

No, either disable MCLR and treat it as an input pin, or keep it enabled and pull it to Vdd with a resistor.  I recommend you keep it enabled unless you actualy need the extra, it will save you from some programming issues that can arise with some programmer designs when MCLR is disabled.

You can also add a push button to ground MCLR to reset the PIC if required, though if you do this it would be a good idea to put a ~0.1uF cap accross the switch to reduce bouncing.  Pullup resistor can typicaly be of the order of 10k-100k, though check the datasheet as always.

Regards

Mike

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2007\03\15@122238 by George Richards

flavicon
face

> According to the datasheet, when i set the PIC to use the internal clock
then it'll be 4MHz. Do I still need to use an external 4MHz oscillator?

The internal oscillator does not require an external 4 MHz oscillator.

2007\03\15@125657 by Alan B. Pearce

face picon face
>No, either disable MCLR and treat it as an input pin, or keep it enabled
>and pull it to Vdd with a resistor.  I recommend you keep it enabled unless
you actually need the extra, it will save you from some programming issues
>that can arise with some programmer designs when MCLR is disabled.

You still need the resistor to Vcc whichever option you choose, as it is
just as dangerous to have the input pin floating.


2007\03\15@131636 by Michael Rigby-Jones

picon face


>-----Original Message-----
>From: KILLspampiclist-bouncesKILLspamspammit.edu [RemoveMEpiclist-bouncesTakeThisOuTspammit.edu]
>On Behalf Of Alan B. Pearce
>Sent: 15 March 2007 16:57
>To: Microcontroller discussion list - Public.
>Subject: Re: [PIC] First shot errors
>
>
>>No, either disable MCLR and treat it as an input pin, or keep it
>>enabled and pull it to Vdd with a resistor.  I recommend you keep it
>>enabled unless
>you actually need the extra, it will save you from some
>programming issues
>>that can arise with some programmer designs when MCLR is disabled.
>
>You still need the resistor to Vcc whichever option you
>choose, as it is
>just as dangerous to have the input pin floating.

Certainly not good practice I agree, which is why I said 'treat it as an input pin'.  However does it actualy cause reset problems if MCLR is disabled and left floating?  I've never disabled MCLR in any of my projects because I've always required external reset control, so don't know all the gotchas appart from the infamous Vpp before Vdd programming issues.

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2007\03\15@164136 by Jan-Erik Soderholm

face picon face
Andrei Yurkevich wrote:
> Also, in most cases it helps to pull down the unused IO-pins on the  
> microcontroller - tie them to GND with 10K~47K resistors.

Or (much easier and does not need any extra hardware)
just set all unsued pins as outputs using the TRIS-regs...

Jan-Erik.

2007\03\15@183108 by Jinx

face picon face
> rlf     PORTB           ; move to RB1

Rikard, it's not recommended to use content-modifying instructions
(incf, decf, rlf, rrf etc) directly on a port. In your case it will probably
work because you're just "moving" an LED. The issue is read-modify-
write. The contents of the port are read, modifed, and then written
back to the port. The problem is that hardware, commonly if any
capacitance is present, may not react as fast as the s/w

http://www.piclist.com/techref/readmodwrite.htm

What would be better for you to do is use a shadow register. This
will be internal RAM and therefore can be modified correctly as fast
as the s/w. When the change has been made, it's written to the port

Like this -

movf portb,w ; read the port
movwf b_shadow ; copy into shadow reister
rlf b_shadow,w ; modify, result in W
movwf portb ; write modified value back to port

As for the delays, I use these routines when all that's needed are
approximate delays. They're easily modified for exact delays, but
with IntRC these are usually good enough

;================================================
;        Delays @ 4MHz Fosc
;================================================

s2       movlw   .20             ;2 second delay
        movwf   del4
dec2     call    ms100           ;call 100ms 20 times
        decfsz  del4
        goto    dec2
        return

ms100    movlw   .156            ;100ms delay
        movwf   del3
        movlw   .5
        movwf   del1
        nop
        nop
        nop
        nop
        nop
next1ms  call    ms1
        nop
        incfsz  del3
        goto    next1ms
        return

ms1      movlw   .10             ;1ms delay
        movwf   del1
lp1      nop
        incfsz  del1
        goto    lp1
        nop
        nop
        return

2007\03\15@184030 by John Dammeyer

flavicon
face
Or if you are using the 18F series use the LAT registers which keep an
image of what you latched out to the parallel port.

John Dammeyer


Automation Artisans Inc.
http://www.autoartisans.com
Ph. 1 250 544 4950


> {Original Message removed}

2007\03\16@014027 by Charles Craft

picon face
What happened to del2?

-----Original Message-----
{Quote hidden}

>-

2007\03\16@030144 by Jinx

face picon face

> What happened to del2?

One day the (sniff) code .... the code went off into
(choke) outer space and del2...................del2 never
came back (blubber). He was such a little trooper

2007\03\16@052128 by Chris Emerson

flavicon
face
On Fri, Mar 16, 2007 at 11:30:14AM +1300, Jinx wrote:
[on using shadow register for avoiding RMW issues]
> movf portb,w ; read the port
> movwf b_shadow ; copy into shadow reister
> rlf b_shadow,w ; modify, result in W
> movwf portb ; write modified value back to port

That looks a lot like a read, modify, and write sequence to me, but just
explicitly in 4 instructions instead of just 1.

Change the above to:

 ; insert banksels as appropriate
 rlf b_shadow, F
 movf b_shadow, W
 movwf PORTB

The point is that you keep a copy of the current output pins in b_shadow
so that you don't have to read PORTB just to change an output pin.  It's
the read that causes the problems, since it reads the actual state of
the pins instead of what you want the outputs to be.  You treat the
shadow register like you would the 18F LAT register, except for having
to copy it to the PORT register yourself when changing it.

Regards,

Chris

2007\03\16@060835 by Jinx

face picon face
>   ; insert banksels as appropriate
>   rlf b_shadow, F
>   movf b_shadow, W
>   movwf PORTB
>
> The point is that you keep a copy of the current output pins in
> b_shadow so that you don't have to read PORTB just to change
> an output pin.  It's the read that causes the problems

Hi Chris, what I gave to Rikard is what you might do generally. Maybe
if you had a mix of I/O, some bits of which you wanted to preserve. A
shadow register may or may not be updated straight away if an input
changes for example, and modifying it without getting the actual state
of the port would lead to an error on the pins

I'd say it's not the read per se that can cause a problem, it's the time
from the last modification. bcf/bsf and NOPS would be an acceptable
solution too in many instances

Ideally you'd know your hardware and do whats' appropriate

2007\03\16@063010 by Chris Emerson

flavicon
face
On Fri, Mar 16, 2007 at 11:08:23PM +1300, Jinx wrote:
> Chris Emerson wrote:
> >   ; insert banksels as appropriate
> >   rlf b_shadow, F
> >   movf b_shadow, W
> >   movwf PORTB
> >
> > The point is that you keep a copy of the current output pins in
> > b_shadow so that you don't have to read PORTB just to change
> > an output pin.  It's the read that causes the problems
>
> Hi Chris, what I gave to Rikard is what you might do generally. Maybe
> if you had a mix of I/O, some bits of which you wanted to preserve. A
> shadow register may or may not be updated straight away if an input
> changes for example, and modifying it without getting the actual state
> of the port would lead to an error on the pins

Input pins don't matter for this - you read them straight from the port
register, and don't care what you write to them.

> I'd say it's not the read per se that can cause a problem, it's the time
> from the last modification. bcf/bsf and NOPS would be an acceptable
> solution too in many instances

Your code referred to above (read PORTB, write to "shadow", modify,
write back to PORTB) doesn't do anything at all to help, though - it's
equivalent to putting a delay between the read and following write, but
the problem is if a write happens shortly after a read.  You're not
using a shadow register, you're using a working register.

> Ideally you'd know your hardware and do whats' appropriate

Maybe, but if there's a simple solution (proper use of shadow registers)
which solves the problem in all cases, without having to measure stray
capacitances, loads, input thresholds, output voltage at maximum pin
load, etc., then that seems better to me.

Regards,

Chris

2007\03\16@140730 by Orin Eman

picon face
On 3/16/07, Chris Emerson <RemoveMEpicspamTakeThisOuTnosreme.org> wrote:
> On Fri, Mar 16, 2007 at 11:30:14AM +1300, Jinx wrote:
> [on using shadow register for avoiding RMW issues]
> > movf portb,w ; read the port
> > movwf b_shadow ; copy into shadow reister
> > rlf b_shadow,w ; modify, result in W
> > movwf portb ; write modified value back to port
>
> That looks a lot like a read, modify, and write sequence to me, but just
> explicitly in 4 instructions instead of just 1.

It is.

{Quote hidden}

I agree.

Another use of a shadow register is if you are using interrupt on
changed bits in PORTB, in which case, you NEVER want to read PORTB
except when you get an interrupt (or poll the interrupt flag).

Orin.

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