Truncated match.
PICList
Thread
'what are the five dumbest things to check?'
1997\12\18@093531
by
Tom Sgouros
|
Hi All:
At the risk of offending the geniuses out there, I have a(nother)
completely dumb question. I have a PIC application that works
beautifully on a microchip demonstration board, and won't work on my
own.
Tring to isolate the problem, I went back to a simple LED-flashing
program (calculating delays from the main crystal). On the demo
board, it also works fine, but on my board it flashes irregularly,
seeming to be "beating" with another much slower frequency. (The
application I am working on has a watch crystal beating a 2-second
period on Timer1, but this appears before the interrupt is enabled.)
So far as I can tell (the 30th time through), the pins are all
connected to the right power. MCLR is tied to 5V through a 4700ohm
resistor. I am using a 16C74. The watchdog timer is disabled, and
there are no interrupts enabled (yet).
There is a 16x4 LCD attached to this all (works on the demo board, but
doesn't initialize on mine), and I wondered if it was pulling the
power down. I haven't been able to detect this, but my test equipment
is pretty rudimentary. What would a pic do that was flirting with the
brown-out protection?
I am not expecting anyone to be able to diagnose my problems remotely,
but I wonder if anyone who remembers their early blundering could jot
down a list of the dumb things to check. I need more things to try,
since I've run out of the things I know about. I feel like I am
overlooking something right in front of my face, but I can't tell what
it is.
I am more or less at my wit's end (an alarmingly short distance), or I
shouldn't have risked bothering you. Many thanks for any help or
advice at all,
-tom
p.s. Many thanks as well for the help I've already been given, both to
questions directly asked, and for help rendered to others in similar
trouble. I'm learning about PICs on my own, and I don't have anybody
here to ask these questions, and to provide reality checks. This
makes this list a remarkably valuable resource, despite the goats,
dutch humor, and other distractions.
----------------------------------------------------------------------
tomss at ids.net - 401-861-2831 - 42 Forge Rd, Potowomut, RI 02818 USA
1997\12\18@103053
by
Mark Dennehy
Tom,
The first thing I find myself checking these days is ground - is the
*bleep* board grounded properly (this after 2 weeks of debugging a serial
line only to find that a 2 inch oiece of wire was the solution :( ) Then,
did I remember to plug in the chip/emulator. Then, did I remember to turn
on the PSU :) All the idiotic things - mainly because I've been taught by
that 16c74a that I am a functional idiot :)
After that, in this case, the oscillator bits in the config word - is it
set to XT or whatever is appropriate ? Then an oscilloscope on the OSC2
pin to make sure the clock is working !
Hope it helps some ...
--
Mark Dennehy, B.A., B.A.I. Email : spam_OUTMark.DennehyTakeThisOuT
cs.tcd.ie
Research Student,
Computer Vision and Robotics Research Group,
Computer Science Dept., Trinity College Dublin
1997\12\18@114054
by
DREITEK
In a message dated 97-12-18 10:29:04 EST, you write:
<<
Hi All:
At the risk of offending the geniuses out there, I have a(nother)
completely dumb question. I have a PIC application that works
beautifully on a microchip demonstration board, and won't work on my
own.
<Snip>
>>
Hello Tom!
Sounds to me like you forgot to set the watchdog timer to off! Your program
is trying to flash the LED but the watch dog timer is resetting the processor
by way of its own time base. The result would be an eratticly flashing LED.
Either turn off the watchdog when you program you part or add a CLRWDT
instruction to your main loop.
Hope this helps
Dave Duley
1997\12\18@130334
by
Keith Howell
|
Observation: Same PIC works on one board but not another.
Axiom: The problem is caused by some difference between the boards.
Thinks: just what are the differences?
If you can't deduce the problem, test it by experiment.
Change the circuit or components step by step until the iffy board
should be exactly like the good one.
At some point, the offending difference should disappear.
What is your app, so we have an idea of how complex it is.
Problems I have met:
People giving me boards with wrong crystal values.
Code not initialising variables to zero
(this reduces the number of random start-up states)
Floating inputs not properly pulled up
(found when debugging an 80C188 design!)
The crystals may be the same frequency, but are they the same cut/mode?
(32.768 xtals are meant to run in Low Power oscillators -
maybe one has be over driven and damaged and ticking erratically)
Try it without the LCD.
> makes this list a remarkably valuable resource, despite the goats,
> dutch humor, and other distractions.
>
> ----------------------------------------------------------------------
> tomss at ids.net - 401-861-2831 - 42 Forge Rd, Potowomut, RI 02818 USA
1997\12\18@132121
by
Tom Sgouros
|
>On Thu, 18 Dec 1997 15:43:12 +0000, Keith Howell wrote:
> Observation: Same PIC works on one board but not another.
> Axiom: The problem is caused by some difference between the boards.
> Thinks: just what are the differences?
> If you can't deduce the problem, test it by experiment.
> Change the circuit or components step by step until the iffy board
> should be exactly like the good one.
> At some point, the offending difference should disappear.
Well, yes, but where to begin? The demo boards are about ten times as
complex as what I need, and I'm not sure which parts are important and
which are only important if I'm using an EEPROM chip or a keypad or a
battery or whatever.
> What is your app, so we have an idea of how complex it is.
It is (embarrassingly) simple. It's similar to an LCD clock, with
regular (2 sec) Timer1 ticks triggering updates to an LCD. There will
be a couple of other inputs, but they're not installed yet, so for
now, it's a clock. (On my board, the code apparently never makes it
to the Timer1 interrupt enable, though.)
> Problems I have met: People giving me boards with wrong crystal
> values. Code not initialising variables to zero (this reduces the
> number of random start-up states) Floating inputs not properly
> pulled up (found when debugging an 80C188 design!) The crystals may
> be the same frequency, but are they the same cut/mode? (32.768
> xtals are meant to run in Low Power oscillators - maybe one has be
> over driven and damaged and ticking erratically) Try it without the
> LCD.
Thanks for the list. I'll be on it tonight.
-tom
----------------------------------------------------------------------
tomss at ids.net - 401-861-2831 - 42 Forge Rd, Potowomut, RI 02818 USA
1997\12\18@162151
by
Mike Keitz
On Thu, 18 Dec 1997 13:24:47 -0500 Tom Sgouros
<.....tomfoolKILLspam
@spam@CIRCUS.GSO.URI.EDU> writes:
>>On Thu, 18 Dec 1997 15:43:12 +0000, Keith Howell wrote:
>
>> Observation: Same PIC works on one board but not another.
>> Axiom: The problem is caused by some difference between the boards.
>> Thinks: just what are the differences?
>Thanks for the list. I'll be on it tonight.
No one seems to have mentioned it yet, but one of the simple mistakes to
make with a larger PIC is not connecting all the power and ground pins.
I think the 74 has 2 ground pins and maybe 2 Vdd pins. All must be wired
in parallel to the circuit's power and ground.
1997\12\18@165845
by
Norm Cramer
I have seen similar behavior when there was ripple on the DC supply to the
board. Check for sufficent capacitance on your 5V supply. It could be
pulling down the supply voltage enough to get a reset. Put the scope on
the Vdd pin and see what it's doing.
I find the best way to trouble shoot is to go from the power supply, to the
MCLR line to the oscillator, then to the ouputs then your inputs.
Hope this helps,
Norm
1997\12\18@171330
by
Tom Rogers
The first thing I always taught my techs was check the supplies. Then, when
they called from the field for help with a tough problem, I always asked if
they checked the supplies. About half the time they went had to go do it and
call back.
So: check the supplies. When doing this, check that there's a good ground
return path and that the PIC is bypassed with a suitable cap or caps (10uf
tant + .01 is good).
Then: get rid of everything but the board, the supplies and the led (w/
current limit, right?). Oh, yeah, and the crystal. Then get that working. If
the same part can't work in the demo board and your board, there's only a
few things that can be wrong, and which should be easy to find.
BTW, if you're not using the same crystal as the demo board, change that,
too. Then, when it works, change to the different crystal and get that
working. Then add the peripherals.
Good Luck. --Tom Rogers
{Original Message removed}
1997\12\18@175802
by
lilel
Nobody's really responded with the five dumbest things yet. Here
they are, with the dumbest first. I've done all of the following:
1. Check if the chip is in backwards (OR wait five minutes for the
chip to start smoking).
2. Check to see if you have 5v (or 3v or whatever).
3. Check to see if you have 5v on the MCLR line.
4. Check to see if you have your watchdog time turned on AND a CLRWDT
statement.
5. Check to see if the oscillator is oscillating.
Nine times out of ten when I have a circuti that doesn't work, its
one of these dumb things AGAIN.
Best Regards,
Lawrence Lile
1997\12\18@192509
by
Marc Heuler
Hi Tom (Tom Sgouros), in <9712181439.AA20275
KILLspamcircus.gso.uri.edu > on Dec 18 you
wrote:
> Tring to isolate the problem, I went back to a simple LED-flashing
> program (calculating delays from the main crystal). On the demo
> board, it also works fine, but on my board it flashes irregularly,
> seeming to be "beating" with another much slower frequency.
Check the XTAL connections.
Double check your LED test program.
Watch the VCC rail on a scope.
Try another PIC.
Build a test circuit that contains _only_ the PIC, LED, XTAL+caps, and
power supply connector.
Go back to top :-)
1997\12\19@005601
by
Wynn Rostek
At 09:39 AM 12/18/97 -0500, you wrote:
>Hi All:
>
>At the risk of offending the geniuses out there, I have a(nother)
>completely dumb question. I have a PIC application that works
>beautifully on a microchip demonstration board, and won't work on my
>own.
If it were me I'd look very carefully at the oscillator. I've seen a lot of
problems there over the years. The other thing I'd check is to make sure
all "unused" pins are pulled up or down, I've seen floating pins cause
interrupts and resets on more than a system or two.
Wynn
1997\12\21@154007
by
Andrew Mayo
|
I have observed that
(a) PICs like a bypass capacitor directly across their power pins
(b) The reset input is noise-sensitive and any tracks to reset should be
as short as possible. Ensure also that the +5V rail is solid and
noise-free, particularly in the area of the reset pullup.
{Quote hidden}> ----------
> From: Wynn Rostek[SMTP:
.....warKILLspam
.....PALMNET.NET]
> Reply To: pic microcontroller discussion list
> Sent: Friday, December 19, 1997 6:30 PM
> To:
EraseMEPICLISTspam_OUT
TakeThisOuTMITVMA.MIT.EDU
> Subject: Re: what are the five dumbest things to check?
>
> At 09:39 AM 12/18/97 -0500, you wrote:
> >Hi All:
> >
> >At the risk of offending the geniuses out there, I have a(nother)
> >completely dumb question. I have a PIC application that works
> >beautifully on a microchip demonstration board, and won't work on my
> >own.
>
> If it were me I'd look very carefully at the oscillator. I've seen a
> lot of
> problems there over the years. The other thing I'd check is to make
> sure
> all "unused" pins are pulled up or down, I've seen floating pins cause
> interrupts and resets on more than a system or two.
>
> Wynn
>
More... (looser matching)
- Last day of these posts
- In 1997
, 1998 only
- Today
- New search...