Searching \ for '[PIC]: Puzzling non-reset behavior' 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: 'Puzzling non-reset behavior'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: Puzzling non-reset behavior'
2003\07\07@183026 by Alex Kilpatrick

flavicon
face
I recently migrated a design from a breadboard to a PCB.  I forgot to
remove my "printf" statements (CCS compiler) that I had used during
debugging.  After many hours of head-scratching, I figured out that the
printf statements were making the pic go off into la-la land.  That in
itself doesn't make sense, but to make matters worse, when the PIC was
in this state, it would not reset.  It took many hours of debugging to
connect these two events.  I eventually figured out that a big (.33 uF)
cap was keeping everything running for a while.  When I discharged it, I
could then reset the PIC properly.
I found the solution to this problem, but I don't know what could be
causing it.  I would like to know, so I can prevent it in the future.  I
have never before been able to get a PIC in a state where it wouldn't
reset.
Any ideas?
Thanks,
ALex

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\07\07@190911 by Ben Jackson

flavicon
face
On Mon, Jul 07, 2003 at 05:30:27PM -0500, Alex Kilpatrick wrote:
>
> I found the solution to this problem, but I don't know what could be
> causing it.  I would like to know, so I can prevent it in the future.  I
> have never before been able to get a PIC in a state where it wouldn't
> reset.

Did you configure MCLR as a an IO?

--
Ben Jackson
<spam_OUTbenTakeThisOuTspamben.com>
http://www.ben.com/

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\07\07@213931 by Alex Kilpatrick

flavicon
face
>
>
> On Mon, Jul 07, 2003 at 05:30:27PM -0500, Alex Kilpatrick wrote:
> >
> > I found the solution to this problem, but I don't know what
> could be
> > causing it.  I would like to know, so I can prevent it in
> the future.  
> > I have never before been able to get a PIC in a state where it
> > wouldn't reset.
>
> Did you configure MCLR as a an IO?
>
No.  That would have been a likely cause, though.

I guess the more fundamental question is:

Can a PIC get in a state while running to where reset does not work?
What would cause this, and how can it be prevented?


Alex

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\07\08@074759 by Olin Lathrop

face picon face
> I recently migrated a design from a breadboard to a PCB.  I forgot to
> remove my "printf" statements (CCS compiler) that I had used during
> debugging.  After many hours of head-scratching, I figured out that the
> printf statements were making the pic go off into la-la land.  That in
> itself doesn't make sense, but to make matters worse, when the PIC was
> in this state, it would not reset.  It took many hours of debugging to
> connect these two events.  I eventually figured out that a big (.33 uF)
> cap was keeping everything running for a while.  When I discharged it, I
> could then reset the PIC properly.

The power doesn't have to go down to reset a PIC.  This can be done by
bringing MCLR low then high again.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\07\08@075835 by Olin Lathrop

face picon face
> Can a PIC get in a state while running to where reset does not work?
> What would cause this, and how can it be prevented?

That depends on what you think will "reset" the PIC.  If MCLR is
configured as MCLR yanking it low then high (while observing the timing
requirements in the manual) should always work.

I did notice to my surprise once that a PIC kept running when MCLR was
pulled low, but did reset properly when it was brought high again.  I
didn't think it was supposed to work this way, but at the time I had
something else pressing to do and forgot about it until now.  I don't
remember which PIC it was, and I didn't spend time checking into it so
something else may have been going on.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\07\08@105042 by Alex Kilpatrick

flavicon
face
>
>
> > I recently migrated a design from a breadboard to a PCB.  I
> forgot to
> > remove my "printf" statements (CCS compiler) that I had used during
> > debugging.  After many hours of head-scratching, I figured out that
> > the printf statements were making the pic go off into la-la land.  
> > That in itself doesn't make sense, but to make matters
> worse, when the
> > PIC was in this state, it would not reset.  It took many hours of
> > debugging to connect these two events.  I eventually
> figured out that
> > a big (.33 uF) cap was keeping everything running for a
> while.  When I
> > discharged it, I could then reset the PIC properly.
>
> The power doesn't have to go down to reset a PIC.  This can
> be done by bringing MCLR low then high again.
>
>
Right, that I do know.  However, in my situation bringing MCLR low, then
high wasn't doing anything.  That's what I meant by "reset."  My
hypothesis is that something in the code was preventing it from
accepting the reset, because when I let the big cap drain, it would
accept a reset again.  That's just a guess, though, because I don't know
if it is possible for any code permutation to get a PIC into a state
where it won't accept a reset (MCLR low-high).

I will admit that my reset is done by remporarily bridging the pin
between MCLR and GND (I have a resistor between VCC and MCLR).  This has
worked 100% for me in the past.

Alex

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\07\08@111709 by Olin Lathrop

face picon face
> Right, that I do know.  However, in my situation bringing MCLR low, then
> high wasn't doing anything.  That's what I meant by "reset."  My
> hypothesis is that something in the code was preventing it from
> accepting the reset,

That's silly.  Let's not stoop to voodoo debugging.  Otherwise just get
out the dead fish and wait for a full moon.

> because when I let the big cap drain, it would
> accept a reset again.

You still haven't said where exactly this cap is.

> I will admit that my reset is done by remporarily bridging the pin
> between MCLR and GND (I have a resistor between VCC and MCLR).  This has
> worked 100% for me in the past.

Are you holding MCLR low for long enough without any contact bounces?
What size resistor?

I know you said you have MCLR configured as MCLR, but have you actually
verified this by reading back the configuration bits from the PIC?


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\07\08@113124 by Peter Moreton

flavicon
face
Olin,

Don't you have to have a hypothesis before you start to search for a
bug? I mean you have to look at the evidence and come up with
hypothetical explanations for the behavior of the code, which you then
test in a debug session.

I agree that 'voodoo programming' does not help, and I have no time for
the folk who when faced with a plain simple programming error resort to
debug techniques such as "lets try booting from my lucky disk", but
nevertheless, you have to come up with some theories before you debug,
otherwise it is pure guesswork!

Peter Moreton




{Original Message removed}

2003\07\08@113808 by Alex Kilpatrick

flavicon
face
>
>
> > Right, that I do know.  However, in my situation bringing MCLR low,
> > then high wasn't doing anything.  That's what I meant by
> "reset."  My
> > hypothesis is that something in the code was preventing it from
> > accepting the reset,
>
> That's silly.  Let's not stoop to voodoo debugging.  
> Otherwise just get out the dead fish and wait for a full moon.
>
Why is that voodoo debugging?  I do X and it fixes Y.  That may have
been a coincidence, but if it is repeatable, then it may be causal.
Olin, you may know that it is impossible for a PIC to get in a code
state where it can't be reset, but I don't know that.

> > because when I let the big cap drain, it would
> > accept a reset again.
>
> You still haven't said where exactly this cap is.
>
It is a .33 uF Cap, across the VCC and GND on a IrDA module.  It is
about 20 mm away from the PIC.

> > I will admit that my reset is done by remporarily bridging the pin
> > between MCLR and GND (I have a resistor between VCC and
> MCLR).  This
> > has worked 100% for me in the past.
>
> Are you holding MCLR low for long enough without any contact
> bounces? What size resistor?
>
I assume so.  As I said, this technique has worked 100% in the past,
through millions :) of resets.  The resistor is 5K.

> I know you said you have MCLR configured as MCLR, but have
> you actually verified this by reading back the configuration
> bits from the PIC?
>
>
Yeah, my programmer does that.  As I mentioned, MCLR does reset fine
after I drain the cap.


Alex

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\07\08@115356 by M. Adam Davis
flavicon
face
How do you bridge the pin?  Make certian conacts aren't dirty.  Also
consider using a 10K or 100K resister to VDD from MCLR.  It could be
that your bridge has enough resistance to still be somewhat above ground
potential when used with the 5k.

Double check your fuses and make certian MCLR is configured as MCLR.

-Adam

Alex Kilpatrick wrote:

{Quote hidden}

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\07\08@121359 by Olin Lathrop

face picon face
Peter Moreton wrote:
> Don't you have to have a hypothesis before you start to search for a
> bug? I mean you have to look at the evidence and come up with
> hypothetical explanations for the behavior of the code, which you then
> test in a debug session.
>
> I agree that 'voodoo programming' does not help, and I have no time for
> the folk who when faced with a plain simple programming error resort to
> debug techniques such as "lets try booting from my lucky disk", but
> nevertheless, you have to come up with some theories before you debug,
> otherwise it is pure guesswork!

No, it isn't.  Not knowing what's wrong does not imply guesswork.  Often
once a system is basically working, you can look at a symptom and be quite
sure what's wrong.  Those are usually the "Oh, yeah, I forgot about that"
bugs.

However when you first try to get something to work the "system doesn't
respond" symptom isn't very useful in narrowing down on the problem.
Aside from checking a few obvious things (power on?, MCLR released?,
oscillator running? ect) it is better to keep an open mind and *not*
assume you know why it's doing what it's doing.  That allows you the
mindset to methodically check everything instead of jumping around spot
checking one hairbrain guess after another.

I've also noticed, especially with inexperienced programmers, that their
guesses are usually wrong and far fetched.  Just check the archives of
this list for lots of incredibly stupid guesses as to why someone's
program doesn't work.  It seems we had several in just the last few days.
First some bozo was trying to tell us the EEPROM read back randomly
(turned out to be bank switching, big surprise), then someone tried to
blame a hardware reset problem on software, and now we've got some rocket
scientist trying to tell us that two INCF FSR don't produce the expected
result.  In all these cases it would have been much more productive NOT to
waste time on wildass guesses and instead spend the effort carefully and
methodically figuring out what IS wrong instead.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\07\08@125420 by Wouter van Ooijen

face picon face
> Olin,
>
> Don't you have to have a hypothesis before you start to search for a
> bug?

(am I allowed to answer?)

Yes, of course, but when asking for outside help (especially when your
own reasoning has not brought the solution - which is probably the case,
otherwise why ask for outside help) it is best to tell the facts, all
the facts, and OK, after that maybe your ideas. But concentrating on the
facts is so important that even explaining them to your cat (kid,
spouse, flower, etc) often brings you enlightment.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\07\08@131117 by Alex Kilpatrick

flavicon
face
>
>
> > Olin,
> >
> > Don't you have to have a hypothesis before you start to
> search for a
> > bug?
>
> (am I allowed to answer?)
>
> Yes, of course, but when asking for outside help (especially
> when your own reasoning has not brought the solution - which
> is probably the case, otherwise why ask for outside help) it
> is best to tell the facts, all the facts, and OK, after that
> maybe your ideas. But concentrating on the facts is so
> important that even explaining them to your cat (kid, spouse,
> flower, etc) often brings you enlightment.
>
> Wouter van Ooijen
>
I don't think I agree with this.  Yes, the facts are the most important,
but a hypothesis, especially a bad one, is a great way to correct a
defective mental model.  As a silly example, if I say that "my PICs keep
dying when I hook +5V to VSS, and I think it is because my power supply
pushes too much current", then it highlights a defective mental model in
my head.  It is a learning opportunity, both for the what the pin labels
on a PIC mean, and also for basic electronics concepts (current draw).

I agree that the act of explaining often solves it.  I have deleted
several emails mid-stream because of this.

Alex

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\07\08@132314 by Alex Kilpatrick

flavicon
face
> >
> > I agree that 'voodoo programming' does not help, and I have no time
> > for the folk who when faced with a plain simple programming error
> > resort to debug techniques such as "lets try booting from my lucky
> > disk", but nevertheless, you have to come up with some
> theories before
> > you debug, otherwise it is pure guesswork!
>
> No, it isn't.  Not knowing what's wrong does not imply
> guesswork.  Often once a system is basically working, you can
> look at a symptom and be quite sure what's wrong.  Those are
> usually the "Oh, yeah, I forgot about that" bugs.
>
When you don't have a depth of understanding, then guesswork is all you
have.  It has a low payoff, but what else can you do?

> However when you first try to get something to work the
> "system doesn't respond" symptom isn't very useful in
> narrowing down on the problem. Aside from checking a few
> obvious things (power on?, MCLR released?, oscillator
> running? ect) it is better to keep an open mind and *not*
> assume you know why it's doing what it's doing.  That allows
> you the mindset to methodically check everything instead of
> jumping around spot checking one hairbrain guess after another.
>
I agree with you on this point.  I think people often want to blame the
hardware (the pic microcode has a bug in it) instead of their own
mistakes.

> I've also noticed, especially with inexperienced programmers,
> that their guesses are usually wrong and far fetched.  
That's what makes them inexperienced.  If you know immediately what is
wrong, then you are experienced.

{Quote hidden}

You know, if it ticks you off so much responding to these "rocket
scientists" and "bozos," then why don't you just ignore them?
Personally, I am grateful for any correction to my understanding of how
the PIC works.  Essentially, "you think it works that way, but it
doesn't"  People build up mental models continually, and as they become
refined they learn and become "experienced," which gives them the right
to laugh at other people's struggles.



Alex

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\07\08@132941 by Dkbovaird

picon face
After you drain the cap? In other words, a complete power cycle?

In my opinion, a .33uf cap is not very big. I would suggest that you remove
this cap, or replace it with a .01uf cap if you feel you need some filtering,
and see how your code works.

I was also curious about what makes you think the pic was not reset by
"bridging" the MCLR pin to ground? Of course changing your code may make the problem
disappear if what you suspect is the cause, but a clear indicator of whether
the chip was reset or not would help.

A series resistor (100ohm) between the MCLR pin and the point where you are
shorting the net to ground could also help. In other words use a 100 ohm
resistor to "short" the MCLR to gnd instead of a direct short with a piece of wire.

dave.

In a message dated 7/8/03 8:39:48 AM Pacific Daylight Time,
.....AlexKKILLspamspam@spam@HCITRAINING.COM writes:

> Yeah, my programmer does that.  As I mentioned, MCLR does reset fine
> after I drain the cap.


--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\07\08@140302 by Mike Singer

picon face
Wouter van Ooijen wrote:
> > Don't you have to have a hypothesis before you start to
> > search for a bug?
>
> (am I allowed to answer?)
>
> Yes, of course,

Of course what? You are "allowed to answer" or this guy is allowed
"to have a hypothesis before starting to search for a bug"? :-)

> ...but when asking for outside help (especially when your
> own reasoning has not brought the solution - which is
> probably the case, otherwise why ask for outside help)
> it is best to tell the facts, all the facts, and OK, after
> that maybe your ideas. But concentrating on the facts is so
> important that even explaining them to your cat (kid, spouse,
> flower, etc) often brings you enlightenment.

Agreed with kid, cat, flower... but am I allowed not to explain PIC
facts to my spouse from safety considerations?

  Mike :-)

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\07\08@140513 by Jeremy Darling

flavicon
face
>> ...but when asking for outside help (especially when your
>> own reasoning has not brought the solution - which is
>> probably the case, otherwise why ask for outside help)
>> it is best to tell the facts, all the facts, and OK, after>>
>> that maybe your ideas. But concentrating on the facts is so
>> important that even explaining them to your cat (kid, spouse,
>> flower, etc) often brings you enlightenment.
>
>Agreed with kid, cat, flower... but am I allowed not to explain PIC
>facts to my spouse from safety considerations?

If I explained anything technical to my wife I wouldn't be able to
type or speak for a while.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\07\08@140646 by Wouter van Ooijen

face picon face
> I don't think I agree with this.  Yes, the facts are the most
> important,

So you do agree. I don't say a hypothesis can not be good additional
info, but only after all the (relevant - that's a difficult point...)
facts.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\07\08@140850 by Wouter van Ooijen

face picon face
> If I explained anything technical to my wife I wouldn't be able to
> type or speak for a while.

Neither would I, but that would be from disbelieve because she pointed
me at an obvious error in my reasoning :)

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\07\08@143210 by John Nall

flavicon
face
At 06:53 PM 7/8/2003 +0200, Wouter wrote:

> >.... but when asking for outside help (especially when your
>own reasoning has not brought the solution - which is probably the case,
>otherwise why ask for outside help) it is best to tell the facts, all
>the facts, and OK, after that maybe your ideas. But concentrating on the
>facts is so important that even explaining them to your cat (kid,
>spouse, flower, etc) often brings you enlightment.

Back many years ago, when I was an undergraduate, I worked in the Computing
Center at the university (only big mainframes in those days).   All of us
"student assistants" had to take our turn at the Help Desk, which was a
place where struggling students could come for help with their programming
assignments.   I found that some 90% percent of the debugging problems were
resolved by just having the student explain to me in detail everything he
(or she) was doing, because inevitably, in explaining the process in
detail, the student would say something like: "Oh!  I see what I did
wrong!"  And all that I had to do was to listen (usually bored to tears). :-)

John

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\07\08@143212 by Olin Lathrop

face picon face
> When you don't have a depth of understanding, then guesswork is all you
> have.  It has a low payoff, but what else can you do?

Go thru everything carefully and meticulously in order.  Single step thru
all paths in the simulator, ICD, and/or debugger.  Characterize the
problem.  Find test cases that always fail.  Eventually you will find the
problem, and on average in less time than by guessing.  Along the way you
will gain the depth of understanding that will help speed the process next
time.

>> I've also noticed, especially with inexperienced programmers,
>> that their guesses are usually wrong and far fetched.
>
> That's what makes them inexperienced.  If you know immediately what is
> wrong, then you are experienced.

Exactly why guessing is a particularly bad idea when you're not really
familiar with the architecture.

The right tools are method and logic.  These are available to anyone,
experienced or not.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\07\08@143213 by Bob Axtell

face picon face
I think that we experienced guys need to have more empathy with the new
folks. Remember, we were new once, too. Remember how hard it was?

That's it.

--Bob

At 12:22 PM 7/8/2003 -0500, you wrote:
{Quote hidden}

---------------
NOTICE

1. This account can accept email & attachments up to 10M in size.
2. Federal Monitors: At request of client, some attachments are encrypted.
Please DO NOT delay traffic; please reply with credentials for password.
--------------

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\07\08@145013 by Mike Singer

picon face
Olin Lathrop wrote:
...some bozo was trying to tell us the EEPROM read back
randomly...

  I like Embed Inc. style of communication, extremely
friendly style. Customers are happy, I'm very sure. :-)

Mike.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\07\08@153103 by Wouter van Ooijen

face picon face
> > When you don't have a depth of understanding, then
> guesswork is all you
> > have.  It has a low payoff, but what else can you do?

When all else fails, you can always bisect (ok, not realy always). Just
cut your program in half, identify the half in which the problem occurs
and half that part again. Proceed untill the remaining code is so small
that the problem is obvious. Sometimes the problem does not occur in
either half, that might be usefull information, or you must just make a
different cut.

I used this method a lot. It is particularly usefull when the problem is
not what you expect, like (in increasing order of difficulty):
- an interaction
- a compiler error
- a hardware logic error
- a hardware intermittent (more or less analog) error

An example of the last type: when writing to a certain memory location
the value of another location would be corrupted. This was caused by
some long address wires (~ 10cm) in combination with a high-impedance
'termination'. When some address lines were all changing from let's say
1 to 0 they would (for a short time) force a 0 onto another address line
that should have stayed 1. After some days of experimenting I reproduced
the problem in software with a few lines of code, without any clue of
the cause. With the aid of the guy who had designed the circuit and a
fast logic analyser we eventually nailed down the problem. I still
consider this the most difficult bug I ever found.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\07\08@153319 by Wouter van Ooijen

face picon face
>   All of us
> "student assistants" had to take our turn at the Help Desk,

I have been an S-A too, in fact I had the reputation of being the S-A to
turn to when none of the others could find the problem. And I also had
the reputation of being the S-A *not* to turn to (for acceptance of an
assignment) when you had copied your solutoin without understanding it,
because I had a satanic satisfaction in detecting this with one or two
questions (after which the victim got a special replacement assignment,
more difficult than the regular ones). I realy liked that job!

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\07\08@154826 by Barry Gershenfeld

face picon face
Maybe have someone else try to do it.   This sounds too much
like a classic "dumb" mistake--only in the sense that you
would never think (or know) to state the condition that
reveals the cause--such as counting the pins wrong, the
screwdriver was plastic, the wire was open inside the
insulation, the program really reset but restarted in the
same place, and so on.

And if you use an ICD...most M'Chip test boards and reference
designs have a resistor between MCLR and the reset button, and
when the ICD is plugged in it overrides the reset button.

Gotta try all angles.  Good luck.

Oh, I almost forgot the obligatory smart-ass remark.  If we
can find an instruction that makes the chip ignore a hard
reset, maybe we can find one that ignores a power down, too ;-)
Sorry, just had to.

Barry

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\07\08@212706 by Alex Kilpatrick

flavicon
face
>
>
> After you drain the cap? In other words, a complete power cycle?
>
I assume so.

> In my opinion, a .33uf cap is not very big. I would suggest
> that you remove this cap, or replace it with a .01uf cap if
> you feel you need some filtering, and see how your code works.
>
It has to be that big for the IrDA module.

> I was also curious about what makes you think the pic was not
> reset by "bridging" the MCLR pin to ground? Of course
> changing your code may make the problem disappear if what you
> suspect is the cause, but a clear indicator of whether the
> chip was reset or not would help.
>
I have an LED sequence that blinks on startup.  I wasn't seeing that
sequence.  When reset worked, it was pretty clear that the chip has
reset.

> A series resistor (100ohm) between the MCLR pin and the point
> where you are shorting the net to ground could also help. In
> other words use a 100 ohm resistor to "short" the MCLR to gnd
> instead of a direct short with a piece of wire.
>
OK, I will try that.  Thanks.

Alex

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\07\08@213122 by Alex Kilpatrick

flavicon
face
>
> Oh, I almost forgot the obligatory smart-ass remark.  If we
> can find an instruction that makes the chip ignore a hard
> reset, maybe we can find one that ignores a power down, too
> ;-) Sorry, just had to.
>
Hey, that would be a useful instruction.  It would certainly extend
battery life.

Alex

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\07\09@015324 by Jinx

face picon face
part 1 558 bytes content-type:text/plain; (decoded 7bit)

>> A series resistor (100ohm) between the MCLR pin

>> instead of a direct short with a piece of wire.

> OK, I will try that.  Thanks.

This is the reset circuit recommended by Microchip

RC ensures that MCLR rises after Vdd, as well as providing
some protection against PSU noise

100R and 220R protect the MCLR pin from excess current when
the reset button is pushed

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




part 2 1383 bytes content-type:image/gif; (decode)


part 3 2 bytes
-

2003\07\09@025101 by Mike Singer

picon face
part 1 458 bytes content-type:text/plain; (decoded 7bit)

Jinx wrote:
> This is the reset circuit recommended by Microchip

How about the diode D, Jinx?

> 100R and 220R protect the MCLR pin from excess current when
> the reset button is pushed

Have look at the text below the circuit(item 3.), please, it
says a bit more :-)

Mike.

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




part 2 1383 bytes content-type:image/gif; (decode)


part 3 7585 bytes content-type:image/gif; (decode)


part 4 2 bytes
-

2003\07\09@032905 by Jinx

face picon face
> How about the diode D

Omitting the external diode assumes that MCLR's internal diode
is intact - it also connects to Vdd. There was some discussion a
long time ago about what breaks in a pin's circuit and what can
stand up to ESD for example. ISTR that it was thought the diode
would be least likely to fail but without hard data that couldn't be
proven. A diode is a very cheap and small component of course
and would be hardly noticed on the board or in the cost. I have to
admit that I have included the external diode on occassion, but
AFAIK *my* circuits and the way I build/design them seem to work
equally well for equally long times with or without the diode

> Have look at the text below the circuit(item 3.), please, it
> says a bit more :-)

A couple of people have cited that MCLR has been broken in normal
operation in circuits that did not have the 220R resistor. One was a
reasonably large run of boards (I don't recall the exact number) that
had a Reset button. After a 220R was added there were no more
MCLR failures. Nothing else was changed and according to the poster
it seemed very unlikely that EOS or ESD was the cause. There were
other, more sensitive, devices on the same Vdd that had no failures

Looking at the text of item 3, you'd have to ask though - if MCLR usage
is an integral part of a circuit then what is there to be gained from
protecting a damaged MCLR from further damage ? "Rearranging the
deckchairs on the Titanic" ?

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

2003\07\09@033515 by Wouter van Ooijen

face picon face
> > How about the diode D
>
> Omitting the external diode assumes that MCLR's internal diode
> is intact - it also connects to Vdd.

There is no such diode, it would be a real PITA for HVP :)

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

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

2003\07\09@055335 by Alan B. Pearce

face picon face
>> I've also noticed, especially with inexperienced programmers,
>> that their guesses are usually wrong and far fetched.
>
>That's what makes them inexperienced.  If you know immediately
>what is wrong, then you are experienced.

Gee I wonder what that makes some of the scientists around here then :))))
They think they know what is wrong, but that doesn't fix it.

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

2003\07\09@055851 by Alan B. Pearce

face picon face
>Oh, I almost forgot the obligatory smart-ass remark.  If we
>can find an instruction that makes the chip ignore a hard
>reset, maybe we can find one that ignores a power down, too ;-)
>Sorry, just had to.

<grin> yeah, the infamous "halt and catch fire" instruction :)

Of course everyone has got sidetracked here in trying to figure out how to
debug, and so have failed their assignment. Perhaps Wouter can be S-A to the
PICList and give new assignments :))

And as to the problem with the chip not resetting, this sounds to me like an
initialised variable somewhere in RAM which the program relies on being in a
certain state for the program to continue, and later gets modified to a
value that causes the program to go into orbit unless the chip is powered
down.

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

2003\07\09@055901 by Brent Brown

picon face
On 9 Jul 2003 at 19:27, Jinx wrote:

> > How about the diode D
>
> Omitting the external diode assumes that MCLR's internal diode
> is intact - it also connects to Vdd. <snip>

Just butting in here so sorry if I'm saying anything previously
said...but surely MCLR would not have the internal diode to Vdd like
regular PIC pins do so that it can be raised to +13V for programming?

--
Brent Brown, Electronic Design Solutions
16 English Street, Hamilton, New Zealand
Ph/fax: +64 7 849 0069
Mobile/txt: 025 334 069
eMail:  RemoveMEbrent.brownTakeThisOuTspamclear.net.nz

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

2003\07\09@064650 by Jinx

face picon face
> Just butting in here so sorry if I'm saying anything previously
> said...but surely MCLR would not have the internal diode to Vdd
> like regular PIC pins do so that it can be raised to +13V for
> programming?

According to Figure 5-5 of DS40300B the F628 does. But the
628 can have MCLR as RA5 and THV too. DS40300B is quite
good in that it shows internal diodes, some manuals don't. I don't
think the 452 manual shows anything much internal for MCLR. As
its MCLR is also Vpp, I wonder if the suggested circuit is a "one
size fits all" for PICs with and without diodes and multiple functions

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

2003\07\09@075627 by Wouter van Ooijen

face picon face
> According to Figure 5-5 of DS40300B the F628 does.

Dunno about that version, but on the current 16F628 datasheet (DS40300C)
fig 5-5 clearly lacks the diode that is present for the other pins.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

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

2003\07\09@080859 by Olin Lathrop

face picon face
> Omitting the external diode assumes that MCLR's internal diode
> is intact

It can't be since there isn't one.  MCLR pins don't have this diode since
the same pin is also Vpp which goes to 13V in normal operation.

I think the purpose of the diode is to prevent current being dumped onto
the Vdd supply during high voltage programming.  If the rest of the
circuit always draws more then 800uA from the Vdd supply, then you can
connect a 10Kohm resistor from Vdd to MCLR and ignore the diode.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

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

2003\07\09@083620 by Nigel Orr

flavicon
face
pic microcontroller discussion list <> wrote on Tuesday, July 08, 2003 4:37
PM:

> It is a .33 uF Cap, across the VCC and GND on a IrDA module.  It is
> about 20 mm away from the PIC.

Getting back to the problem, could you post the blinky LED code that you
are
using, which isn't working on MCLR reset?

It probably _is_ being run, but some initialisation condition is different
on power on from MCLR.  Have a look at the initialisation condition for the
special function registers in the datasheet (DS40300C pg.15 ff for the
16f628).  A few registers are 'unknown' state at startup (and could be
consistently different after MCLR reset from power up reset), you might be
relying on some of them being initialised?

Can you move your LED blink code right to the top of the code, so it will
be easier to track if it is running?  If you start from the assumption that
it _is_ resetting, you might find the _real_ fault... engineers who accept
that they are fallible usually solve problems faster!

Nigel
--
Nigel Orr, Design Engineer                 EraseMEnigelspamaxoninstruments.co.uk
Axon Instruments Ltd., Wardes Road,Inverurie,Aberdeenshire,UK,AB51 3TT
              Tel:+44 1467 622332 Fax:+44 1467 625235
                  http://www.axoninstruments.co.uk

2003\07\09@083657 by Jinx

face picon face
part 1 409 bytes content-type:text/plain; (decoded 7bit)

> It can't be since there isn't one.  MCLR pins don't have this diode since
> the same pin is also Vpp which goes to 13V in normal operation.

> *****************************************************************
> Embed Inc,

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




part 2 4544 bytes content-type:image/gif; (decode)


part 3 2 bytes
-

2003\07\09@085813 by Wouter van Ooijen

face picon face
> (gif)

Probably a uChip blooper, download the latest datasheet and compare.

Even RTFM does not absolve you from thinking for yourself ;)

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

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

2003\07\09@132125 by Peter L. Peres

picon face
>   I like Embed Inc. style of communication, extremely
> friendly style. Customers are happy, I'm very sure. :-)

I think that he has a flamethrower under the counter of their shop, where
others have a baseball bat (think downtown pub). I also think that he uses
it from time to time on random clients. Just to keep well-practiced.

Peter

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

2003\07\09@135455 by Davd P Harris

picon face
Hi-
I just looked at the 628A schematic, figure 5-5 in
www.microchip.com/download/lit/pline/picmicro/families/16c62x/40300c.pdf
, page 31, and it shows a diode to Vss, but no diode to Vdd.
David

Jinx wrote:

{Quote hidden}

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

2003\07\09@145129 by Olin Lathrop

face picon face
>> It can't be since there isn't one.  MCLR pins don't have this diode
>> since the same pin is also Vpp which goes to 13V in normal operation.
>
> [attached picture of data sheet showing diode from MCLR to Vdd
> 16F62x]

OK, I see the manual clearly shows the diode, and I found the same
illustration in my copy (page 30 of DS40300B).  However, people write data
sheets, and people occasionally make mistakes.  This is one of those
relatively rare times when I am very skeptical of the manual.  It just
doesn't make sense.  How can MCLR be raised to 13V during programming and
still keep Vdd at 5V if that diode is really there?  I stongly suspect
that whoever drew that diagram started by copying the diagram for another
pin (a reasonable thing to do), and just forgot to delete the diode.
Although Microchip manuals are really quite good, it wouldn't be the first
error I've seen in them.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

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

2003\07\09@160135 by Wouter van Ooijen

face picon face
> OK, I see the manual clearly shows the diode, and I found the same
> illustration in my copy (page 30 of DS40300B).

Olin, this is a case of RTLFM (L = latest) :)

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

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

2003\07\09@163904 by Mike Singer

picon face
part 1 628 bytes content-type:text/plain; (decoded 7bit)

Olin Lathrop wrote:
> I think the purpose of the diode is to prevent current being
> dumped onto the Vdd supply during high voltage programming.
> If the rest of the circuit always draws more then 800uA from
> the Vdd supply, then you can connect a 10Kohm resistor from
> Vdd to MCLR and ignore the diode.

If you wrote about diode D on attached scheme, then it's purpose
is described clearly in item 1 of the text below the scheme.

Mike.

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




part 2 7585 bytes content-type:image/gif; (decode)


part 3 2 bytes
-

2003\07\09@171334 by Jinx

face picon face
> Probably a uChip blooper, download the latest datasheet and compare.

OK OK, I'll take 50% of the rap. I'd rather MC got manuals right first time

> Even RTFM does not absolve you from thinking for yourself ;)

Oh absolutely. And btw, the smiley made all the difference - kicking
a trier isn't a good look ;)

I'd still question item 3 in that excerpt Mike Singer posted.- why protect
a blown chip.  Is damage to MCLR a foot in the door for complete chip
failure that could affect port pins for example ? Academic I guess if the
initial damage is avoided

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

2003\07\09@192443 by Alex Kilpatrick

flavicon
face
>
> > It is a .33 uF Cap, across the VCC and GND on a IrDA module.  It is
> > about 20 mm away from the PIC.
>
> Getting back to the problem, could you post the blinky LED code that
you
> are
> using, which isn't working on MCLR reset?
>
> It probably _is_ being run, but some initialisation condition is
different
> on power on from MCLR.  Have a look at the initialisation condition
for
> the
> special function registers in the datasheet (DS40300C pg.15 ff for the
> 16f628).  A few registers are 'unknown' state at startup (and could be
> consistently different after MCLR reset from power up reset), you
might be
> relying on some of them being initialised?
>
The code is just setting an output low and waiting 200 mS.  It isn't
dependent upon any registers.  
Thanks for the suggestion.

Alex

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

2003\07\09@193108 by Sean H. Breheny

face picon face
How are you delaying the 200msec though? Does that use registers (unless
you have a really long string of nops hard coded I would think that it
would). Also, is the output set lot immediately upon restart? Do you do
anything after the 200msec delay?

Sean

At 06:24 PM 7/9/2003 -0500, you wrote:
{Quote hidden}

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

2003\07\10@034431 by Jinx

face picon face
> Can a PIC get in a state while running to where reset does not work?
> What would cause this, and how can it be prevented?

It really sounds as though MCLR has been disabled. What PIC
are you using ?

If it's still going off into la-la land perhaps a trap somewhere high
in memory past the end of your code that sets a pin high you
can detect

--
http://www.piclist.com hint: To leave the PICList
TakeThisOuTpiclist-unsubscribe-request.....spamTakeThisOuTmitvma.mit.edu>

2003\07\10@050227 by Nigel Orr

flavicon
face
pic microcontroller discussion list <> wrote on Thursday, July 10, 2003
12:25 AM:

> The code is just setting an output low and waiting 200 mS.  It isn't
> dependent upon any registers.

That would be a clever trick, unless you have 1000 nop's and a 20kHz clock
:-).  I suspect you are using at least 2 registers, as well as STATUS, port
and tristate access... and that is _more_ than enough room to make mistakes
in.  I know, I've done it :-)

If you can't post the chunk of code (NDA, sheer embarassment, whatever),
just say so (but then we probably can't help.  If you can post everything
from 'org 0' until the LED goes off (or a chunk of code which replicates
the problem on your hardware) (including interrupt service routines etc),
then someone might be able to sort it out.  Until then, I still suspect
it's a bug in the code, not in the chip.

But I could be wrong...

Nigel
--
Nigel Orr, Design Engineer                 TakeThisOuTnigelKILLspamspamspamaxoninstruments.co.uk
Axon Instruments Ltd., Wardes Road,Inverurie,Aberdeenshire,UK,AB51 3TT
              Tel:+44 1467 622332 Fax:+44 1467 625235
                  http://www.axoninstruments.co.uk

2003\07\10@085806 by Alex Kilpatrick

flavicon
face
Yeah, I will need you all to sign an NDA for my blinking LED code.  :-)

I'm using the CCS compiler.  The code looks like this:

Output_low(PIN_A1);
Delay_ms(200);
Output_high(PIN_A1);

I'm not sure how the compiler generates these delays.  I know it does
use nops for some of them.  I will take a look at it and see what it
does.

However, I pretty much always have a few blinks as the first thing in my
code, so I know whether the chip has restarted or not.  You guys are
saying that there may be a bug in my code that is preventing this
blinking from happening.  So you are saying that the chip is resetting,
but errors in my code are preventing this from appearing.

I don't think that's it, though.  I have built two of these boards, both
running the same exact software.  One of them "resets" just fine, and I
get the blinking LEDs I expect.  The other one only "resets" if I make
sure it has a complete power down.  That doesn't seem like a software
bug to me, it seems like a hardware bug.  I certainly don't think it is
a big in the PIC, I think it is some kind of weird electrical thing on
the board.  Maybe a bad solder joint on the MCLR resistor or something.

Alex


> {Original Message removed}

2003\07\10@085810 by Alex Kilpatrick

flavicon
face
>
> > Can a PIC get in a state while running to where reset does not work?
> > What would cause this, and how can it be prevented?
>
> It really sounds as though MCLR has been disabled. What PIC
> are you using ?
>
That is a config bit, right?  On this board, the PIC will reset if all
the power is removed for a little while.  Just not while the chip is
powered.

Alex

--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-requestspamRemoveMEmitvma.mit.edu>

2003\07\10@093101 by Jinx

face picon face
> It really sounds as though MCLR has been disabled. What PIC
> are you using ?
>

> That is a config bit, right?

Yes, bit5. If it's not set = 0 in the CONFIG statement then it will be
the default "1", which is MCLR active. Config is untouchable except
during programming AFAIK

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestspamspamBeGonemitvma.mit.edu>

2003\07\10@093108 by Jinx

face picon face
> I don't think that's it, though.  I have built two of these boards, both
> running the same exact software.  One of them "resets" just fine, and I
> get the blinking LEDs I expect.  The other one only "resets" if I make
> sure it has a complete power down

What happens if you swap the two PICs or replace the "faulty" PIC
with a new one ?

--
http://www.piclist.com hint: To leave the PICList
spamBeGonepiclist-unsubscribe-request@spam@spamspam_OUTmitvma.mit.edu>

2003\07\10@093917 by Alex Kilpatrick

flavicon
face
>
>
> > I don't think that's it, though.  I have built two of these boards,
> > both running the same exact software.  One of them "resets"
> just fine,
> > and I get the blinking LEDs I expect.  The other one only
> "resets" if
> > I make sure it has a complete power down
>
> What happens if you swap the two PICs or replace the "faulty"
> PIC with a new one ?
>
Well, since it is SSOP (SMT) I am reluctant to do that.  I don't have
the couple of hours it would take to unsolder/resolder.  :-)

Again, I don't think the PIC is faulty.  I think it is something faulty
on the board.  Maybe the MCLR resistor or something.

Alex

--
http://www.piclist.com hint: To leave the PICList
TakeThisOuTpiclist-unsubscribe-requestspamspammitvma.mit.edu>

2003\07\10@094339 by Alex Kilpatrick

flavicon
face
>
>
> > It really sounds as though MCLR has been disabled. What PIC are you
> > using ?
> >
>
> > That is a config bit, right?
>
> Yes, bit5. If it's not set = 0 in the CONFIG statement then
> it will be the default "1", which is MCLR active. Config is
> untouchable except during programming AFAIK
>
Right.  However, the chip does reset when it is running normally (not in
la-la land), so I know the config bit is fine.  And the config bit can't
change during operation, as you mentioned.

Alex

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestEraseMEspammitvma.mit.edu>

2003\07\10@094720 by Jinx

face picon face
> Again, I don't think the PIC is faulty.  I think it is something faulty
> on the board.  Maybe the MCLR resistor or something.

Substitution is going to tell you one way or the other. I know it can be
a pain and I appreciate the reluctance, but sometimes you just have
to do it

It may even be the merest whisker of a solder bridge under the chip
that will vanish when you desolder. I think after two days I'd be getting
desperate enough so I could move on. Have you checked for shorts ?

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestEraseMEspamspam_OUTmitvma.mit.edu>

2003\07\10@102012 by Alex Kilpatrick

flavicon
face
>
>
> > Again, I don't think the PIC is faulty.  I think it is something
> > faulty on the board.  Maybe the MCLR resistor or something.
>
> Substitution is going to tell you one way or the other. I
> know it can be a pain and I appreciate the reluctance, but
> sometimes you just have to do it
>
> It may even be the merest whisker of a solder bridge under
> the chip that will vanish when you desolder. I think after
> two days I'd be getting desperate enough so I could move on.
> Have you checked for shorts ?
>
I'm actually not desperate.  I made another board with the same
software, and it works fine.  That is essentially the same thing as
swapping out the hardware.  I'm confident that it is something on the
board itself.

Alex

--
http://www.piclist.com hint: To leave the PICList
@spam@piclist-unsubscribe-requestRemoveMEspamEraseMEmitvma.mit.edu>

2003\07\10@102429 by Nigel Orr

flavicon
face
pic microcontroller discussion list <> wrote on Thursday, July 10, 2003
1:33 PM:

> Yeah, I will need you all to sign an NDA for my blinking LED code.

So can I use it in my projects, licence free?  Wow, thanks :-) :-)

> I'm using the CCS compiler.  The code looks like this:
>
> Output_low(PIN_A1);
> Delay_ms(200);
> Output_high(PIN_A1);

That's very interesting, but does it produce any assembler :-)  There is
probably a .LST file or even .ASM file created, which will show what it is
actually doing from startup.  As it's a C compiler, I would expect that the
above 3 lines will use quite a few resources to blink the LED, not a string
of nop's!

Does pin A1 have any other function on the chip you are using (eg
comparator input etc).  I'm sure you mentioned which PIC it was, could you
remind me?

What registers need to be set to disable the other functions?

Can you check the assembler to verify that they are set correctly?

Are the above instructions the first three instructions in main(), or do
you have additional startup code (I don't use CCS, does it handle tristates
etc for you, if it doesn't, then I wouldn't expect the above code to work,
pins are set as inputs on boot)

Are the PICs socketed?  Can you swap them over to see if the fault follows
the PIC or the board?

Do you have a 'scope?  Can you look at the MCLR waveform on the actual pin
(not on the solder blob or the PCB) on reset to see what it is doing?  Have
you tried to remake the solder joints around the MCLR resistor which you
think might be suspect?  If you don't have a 'scope, a) try to get one, b)
Check with a multimeter what voltage is on the actual pin (again, not the
pad or the solder, there might be a subtle dry joint!) when reset is
asserted and released.

You could also have a visual check around MCLR to inspect solder joints.

A few pointers to be going on with, these are all standard debug thoughts
that you can store away for next time, even if they don't find the problem
this time!  Once you've tried them, let us know what the result was, and
we'll go one from there.

As you mentioned that you have 2 boards, one working and one not, try to
test both of them and compare what happens.

Nigel
--
Nigel Orr, Design Engineer                 EraseMEnigelspam@spam@axoninstruments.co.uk
Axon Instruments Ltd., Wardes Road,Inverurie,Aberdeenshire,UK,AB51 3TT
              Tel:+44 1467 622332 Fax:+44 1467 625235
                  http://www.axoninstruments.co.uk

2003\07\10@103913 by Nigel Orr

flavicon
face
pic microcontroller discussion list <> wrote on Thursday, July 10, 2003
2:42 PM:

> Right.  However, the chip does reset when it is running normally (not
> in la-la land), so I know the config bit is fine.  And the config bit
> can't change during operation, as you mentioned.

Presuming that "la-la land" isn't where you want the PIC to be, have you
any idea what is making it go there?  Maybe if you have, someone could
suggest how that might combine with some difference between MCLR and power
up to cause the symptoms you are seeing?

Is the PIC voltage supply stable?  Could it be dropping to an out of spec
level when the PIC goes to "la-la land", eg if the PIC is driving an output
high which is connected to ground when it gets confused?

Nigel
--
Nigel Orr, Design Engineer                 @spam@nigelspam_OUTspam.....axoninstruments.co.uk
Axon Instruments Ltd., Wardes Road,Inverurie,Aberdeenshire,UK,AB51 3TT
              Tel:+44 1467 622332 Fax:+44 1467 625235
                  http://www.axoninstruments.co.uk

2003\07\10@104741 by David VanHorn

flavicon
face
At 03:24 PM 7/10/2003 +0100, Nigel Orr wrote:

>pic microcontroller discussion list <> wrote on Thursday, July 10, 2003
>1:33 PM:
>
>> Yeah, I will need you all to sign an NDA for my blinking LED code.
>
>So can I use it in my projects, licence free?  Wow, thanks :-) :-)
>
>> I'm using the CCS compiler.  The code looks like this:
>>
>> Output_low(PIN_A1);
>> Delay_ms(200);
>> Output_high(PIN_A1);

Wouldn't you need a delay after the output high, so you can see the led is on?

Fortunately, you can licence my patent on time-varible visual response modifiers used with photic emitters.

:)

--
http://www.piclist.com hint: To leave the PICList
spamBeGonepiclist-unsubscribe-requestEraseMEspammitvma.mit.edu>

2003\07\10@111105 by Alex Kilpatrick

flavicon
face
>
> > I'm using the CCS compiler.  The code looks like this:
> >
> > Output_low(PIN_A1);
> > Delay_ms(200);
> > Output_high(PIN_A1);
>
> That's very interesting, but does it produce any assembler
> :-)  There is probably a .LST file or even .ASM file created,
> which will show what it is actually doing from startup.  As
> it's a C compiler, I would expect that the above 3 lines will
> use quite a few resources to blink the LED, not a string of nop's!
>
Here is what it says in the documentation:
--
This function will create code to perform a delay of the specified
length.  Time is specified in milliseconds.  This function works by
executing a precise number of instructions to cause the requested delay.
It does not use any timers.  If interrupts are enabled the time spent in
an interrupt routine is not counted toward the time.
--

I created a simple CCS C program with just a 10 us delay.  Here is the
relevant assembler:

....................    delay_us(10);
0009:  MOVLW  03
000A:  MOVWF  20
000B:  DECFSZ 20,F
000C:  GOTO   00B

> Does pin A1 have any other function on the chip you are using
> (eg comparator input etc).  I'm sure you mentioned which PIC
> it was, could you remind me?
>
No.  I am using a 16F628.

[snip good debugging approaches]

{Quote hidden}

I am kind of interested in an abstract way, but I don't have the time to
investigate this further.  Once I built a board that works, I know there
is not a flaw in my software or hardware *design*, even if there may be
a problem in one particular instance.  I am building this for a proof-of
concept demo, and I am much more concerned about the functionality of
the device.  If I were planning to manufacture 100,000 of these, I might
be more worried about my manufacturing processes.  I already know my SMT
soldering is suspect.  :-)

Alex

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestspamBeGonespammitvma.mit.edu>

2003\07\10@111235 by Alex Kilpatrick

flavicon
face
> >
> >> I'm using the CCS compiler.  The code looks like this:
> >>
> >> Output_low(PIN_A1);
> >> Delay_ms(200);
> >> Output_high(PIN_A1);
>
> Wouldn't you need a delay after the output high, so you can
> see the led is on?
>
No, the anode of the LED is connected to the PIC.  The cathode is
connected to +3.  
I generally do this, since PICs can sink more current than they can
supply, right?

> Fortunately, you can licence my patent on time-varible visual
> response modifiers used with photic emitters.
>
> :)

Thanks!  Can I get that in writing?

Alex

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-request@spam@spamspamBeGonemitvma.mit.edu>

2003\07\10@112111 by Alex Kilpatrick

flavicon
face
>
>
> pic microcontroller discussion list <> wrote on Thursday,
> July 10, 2003 2:42 PM:
>
> > Right.  However, the chip does reset when it is running
> normally (not
> > in la-la land), so I know the config bit is fine.  And the
> config bit
> > can't change during operation, as you mentioned.
>
> Presuming that "la-la land" isn't where you want the PIC to
> be, have you any idea what is making it go there?  Maybe if
> you have, someone could suggest how that might combine with
> some difference between MCLR and power up to cause the
> symptoms you are seeing?
>
I am using La-la land to simply mean that the PIC is somewhere that I
don't understand.  The basic sructure of the code is a loop that just
sleeps.  The PIC wakes up in response to an external interrupt.  When it
is in la-la land, it isn't waking up.  It could be anything -- an
infinite loop, or whatever.

> Is the PIC voltage supply stable?  Could it be dropping to an
> out of spec level when the PIC goes to "la-la land", eg if
> the PIC is driving an output high which is connected to
> ground when it gets confused?
>
It goes into la-la land when it gets to a serial output (printf in CCS)
statement.  On this board, that isn't connected to anything, but it may
be possible that there is a solder bridge between that pin and a GND
signal.  That could definitley drop the voltage below spec, since it is
just a lithium battery.  If that happened, I could see how the PIC
wouldn't respond to a reset, because the voltage would still be too low.


I will definitelty have to check that out.

Alex
--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-request@spam@spamEraseMEmitvma.mit.edu>

2003\07\10@112113 by David VanHorn

flavicon
face
At 10:12 AM 7/10/2003 -0500, Alex Kilpatrick wrote:

>> >
>> >> I'm using the CCS compiler.  The code looks like this:
>> >>
>> >> Output_low(PIN_A1);
>> >> Delay_ms(200);
>> >> Output_high(PIN_A1);
>>
>> Wouldn't you need a delay after the output high, so you can
>> see the led is on?
>>
>No, the anode of the LED is connected to the PIC.  The cathode is
>connected to +3.

Ok, then this should show constant on, unless there's a hidden delay when the code loops.


>> Fortunately, you can licence my patent on time-varible visual
>> response modifiers used with photic emitters.
>>
>> :)
>
>Thanks!  Can I get that in writing?

I think maybe we can cross licence, I like your method of intelligence conveyance by intermittently variable illumination.

--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-requestRemoveMEspammitvma.mit.edu>

2003\07\10@114004 by Alex Kilpatrick

flavicon
face
>
> >> >
> >> >> I'm using the CCS compiler.  The code looks like this:
> >> >>
> >> >> Output_low(PIN_A1);
> >> >> Delay_ms(200);
> >> >> Output_high(PIN_A1);
> >>
> >> Wouldn't you need a delay after the output high, so you
> can see the
> >> led is on?
> >>
> >No, the anode of the LED is connected to the PIC.  The cathode is
> >connected to +3.
>
> Ok, then this should show constant on, unless there's a
> hidden delay when the code loops.
>
Hmm?  Cathode is positive, right?

+5 ---   -> (LED)  ----  PIC

A1 is normally high (not shown in code).  I bring it low, the LED comes
on.  I wait 200 ms.  Then it goes high and the LED turns off.  Am I
missing something here?

Alex

--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-requestSTOPspamspam@spam@mitvma.mit.edu>

2003\07\10@114006 by Dale Botkin

flavicon
face
On Thu, 10 Jul 2003, Alex Kilpatrick wrote:

> > >> I'm using the CCS compiler.  The code looks like this:
> > >>
> > >> Output_low(PIN_A1);
> > >> Delay_ms(200);
> > >> Output_high(PIN_A1);
> >
> > Wouldn't you need a delay after the output high, so you can
> > see the led is on?
> >
>
> No, the anode of the LED is connected to the PIC.  The cathode is
> connected to +3.

Matters not.  Here is what you're doing:

Turn LED on for 200ms
Turn LED off for 1uS
Turn LED on for 200ms

See a problem there?

> I generally do this, since PICs can sink more current than they can
> supply, right?

Some can, some cannot.  Check the data sheet.  But it's immaterial if you
are not trying to run 20-25mA to the LED.  If you have a current limiting
resistor in series with the LED to less than 20mA, then who cares whether
the pin can do 20 or 25mA in that direction?  Having said that, either way
is fine.

Dale
--
It's a thankless job, but I've got a lot of Karma to burn off.
Get a PicoKeyer: http://www.hamgadgets.com

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestEraseMEspam@spam@mitvma.mit.edu>

2003\07\10@115634 by Alan B. Pearce

face picon face
>I already know my SMT soldering is suspect.  :-)

well surely the first step in this particular debugging process is to get to
a point where the hardware can be considered reliable, instead of suspect,
ain't it?

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestspamspamBeGonemitvma.mit.edu>

2003\07\10@122551 by Olin Lathrop

face picon face
> No, the anode of the LED is connected to the PIC.  The cathode is
> connected to +3.

That's a strange way to drive an LED.  LEDs should be driven with a known
current.  The actual voltage should be allowed to vary, and is usually
around 2V for normal LEDs (not blue or white), but depends on batch,
temperature, etc.  Your method connects a fixed 2V to the LED, which is a
bad idea.

> I generally do this, since PICs can sink more current than they can
> supply, right?

How am possibly supposed to know why you generally do this!?  However,
it's a bad idea in any case.

PICs are a little bit better at sinking current than sourcing it, but note
that in your method the PIC sources current into the LED.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: To leave the PICList
spamBeGonepiclist-unsubscribe-requestKILLspamspam@spam@mitvma.mit.edu>

2003\07\10@123425 by Alex Kilpatrick

flavicon
face
> -----Original Message-----
> From: Olin Lathrop [olin_piclistspam_OUTspam@spam@EMBEDINC.COM]
> Sent: Thursday, July 10, 2003 11:25 AM
> To: spamBeGonePICLIST@spam@spamMITVMA.MIT.EDU
> Subject: Re: [PIC]: Puzzling non-reset behavior
>
>
> > No, the anode of the LED is connected to the PIC.  The cathode is
> > connected to +3.
>
> That's a strange way to drive an LED.  LEDs should be driven
> with a known current.  The actual voltage should be allowed
> to vary, and is usually around 2V for normal LEDs (not blue
> or white), but depends on batch, temperature, etc.  Your
> method connects a fixed 2V to the LED, which is a bad idea.
>
Whoops.  I forgot to mention the current limiting resistor:

+3V --  LED ->  --  40 ohm -- PIC

Alex

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestEraseMEspamKILLspammitvma.mit.edu>

2003\07\10@132131 by Olin Lathrop

face picon face
>>> No, the anode of the LED is connected to the PIC.  The cathode is
>>> connected to +3.
>>
>> That's a strange way to drive an LED.  LEDs should be driven
>> with a known current.  The actual voltage should be allowed
>> to vary, and is usually around 2V for normal LEDs (not blue
>> or white), but depends on batch, temperature, etc.  Your
>> method connects a fixed 2V to the LED, which is a bad idea.
>>
>
> Whoops.  I forgot to mention the current limiting resistor:
>
> +3V --  LED ->  --  40 ohm -- PIC

That still won't work, but it will at least prevent damage to the LED or
the PIC.  Since the LED on voltage is probably around 2V, you may or may
not get much current thru it when trying to turn it on since you are
driving it with 2V when the PIC pin is high.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: To leave the PICList
spamBeGonepiclist-unsubscribe-requestspam_OUTspamRemoveMEmitvma.mit.edu>

2003\07\10@142047 by Barry Gershenfeld

face picon face
Re: Dave: You are right about no delay after the light is turned off,
but he probably doesn't even see the LED come on.

Re: Mr. KnowItAll: The fact that all his other boards light up
and so does this one after he does the power cycle, suggests
that he is onto something with the LED and resistor.

Re: CCS delays: The timing loop is "calibrated" using the #USE CLOCK
statement where you tell it how fast the oscillator runs.

Re: Alex: When you said "bridge" I pictured a screwdriver blade inserted
between the MCLR and ground pins--obviously it isn't conveniently pinned
out that way, and you said it's not a DIP...But the SMT way would be
to get a voltmeter probe onto MCLR while you do your "reset" (however
it's done) and see that the pin goes low.  That will help you find
a variety of oops'es.

And I wanted to make sure you understand that MCLR is a hardware
function that gets in below the level of the software, registers,
etc., so it "has to" work.  ("has to" being accompanied by a
slight wink)

Eventually I see this board being passed around from member to
member until someone finds it...

Barry

--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-requestspamRemoveMEmitvma.mit.edu>

2003\07\10@142250 by Alex Kilpatrick

flavicon
face
> >>
> >
> > Whoops.  I forgot to mention the current limiting resistor:
> >
> > +3V --  LED ->  --  40 ohm -- PIC
>
> That still won't work, but it will at least prevent damage to
> the LED or the PIC.  Since the LED on voltage is probably
> around 2V, you may or may not get much current thru it when
> trying to turn it on since you are driving it with 2V when
> the PIC pin is high.
>
I'm not driving it when the PIC is high, I am driving it when the PIC is
low.  The PIC is running at 3V.

Alex

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestspam@spam@mitvma.mit.edu>

2003\07\10@142910 by Alex Kilpatrick

flavicon
face
>
> Re: Dave: You are right about no delay after the light is
> turned off, but he probably doesn't even see the LED come on.
>
I should have mentioned that the PIC is running at 3V, giving me:

3V -> LED -> Res -> Pic

The LED comes on when the PIC outputs a low.  Therefore, a
low-delay-high lets me see the LED.  Sheesh.  I did figure out how to
turn on an LED a while back.  I don't need you guys to do further
analysis on this.  :-)

> Re: CCS delays: The timing loop is "calibrated" using the
> #USE CLOCK statement where you tell it how fast the oscillator runs.
>
Yes.

> Re: Alex: When you said "bridge" I pictured a screwdriver
> blade inserted between the MCLR and ground pins--obviously it
> isn't conveniently pinned out that way, and you said it's not
> a DIP...But the SMT way would be to get a voltmeter probe
> onto MCLR while you do your "reset" (however it's done) and
> see that the pin goes low.  That will help you find a variety
> of oops'es.
>
That's how I reset it, with a screwdriver.  (a tiny one, since it is
SMT).  
> And I wanted to make sure you understand that MCLR is a
> hardware function that gets in below the level of the
> software, registers, etc., so it "has to" work.  ("has to"
> being accompanied by a slight wink)
>
Yes, I have gathered that most thoroughly.  :-)  
> Eventually I see this board being passed around from member
> to member until someone finds it...
>
Yes, I never planned to get this much discussion.  I feel like I am on
trial now.  :-)

Forget I asked!!!  I don't care anymore!!!

<pbbbttt>

Alex

--
http://www.piclist.com hint: To leave the PICList
EraseMEpiclist-unsubscribe-requestRemoveMEspamSTOPspammitvma.mit.edu>

2003\07\10@154551 by Olin Lathrop

face picon face
> I'm not driving it when the PIC is high, I am driving it when the PIC is
> low.  The PIC is running at 3V.

But that contradicts your earlier statement of having the cathode
connected to 3V.  If the cathode is tied to a 3V rail, then the LED can
only go on when the anode is raised above 3V.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestKILLspamspamTakeThisOuTmitvma.mit.edu>

2003\07\10@155838 by Alex Kilpatrick

flavicon
face
>
>
> > I'm not driving it when the PIC is high, I am driving it
> when the PIC
> > is low.  The PIC is running at 3V.
>
> But that contradicts your earlier statement of having the
> cathode connected to 3V.  If the cathode is tied to a 3V
> rail, then the LED can only go on when the anode is raised above 3V.
>
Sorry.  I always get those mixed up.  
I keep wanting to think of cathode as positive, therefore tied to +V.

When I drew the diagram, I used a -> for the LED, to try to make it
clear which way to LED was wired.

I admit it was confusing when I had the 3V in there without specifying
that was the same as the supply voltage.  I couldn't figure out where
you were getting 2V from, until I remembered that 5-3 = 2.  :-)

Alex

--
http://www.piclist.com hint: To leave the PICList
spamBeGonepiclist-unsubscribe-requestspam@spam@mitvma.mit.edu>

2003\07\10@163536 by Bob Axtell

face picon face
At 01:21 PM 7/10/2003 -0400, you wrote:
> >>> No, the anode of the LED is connected to the PIC.  The cathode is
> >>> connected to +3.
> >>
> >> That's a strange way to drive an LED.  LEDs should be driven
> >> with a known current.  The actual voltage should be allowed
<respectfully snipped>

Obviously, Alex, you're NOT getting out of here alive....

<g>

--Bob
---------------
NOTICE

1. This account can accept email & attachments up to 10M in size.
2. Federal Monitors: At request of client, some attachments are encrypted.
Please DO NOT delay traffic; please reply with credentials for password.
--------------

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestspam_OUTspammitvma.mit.edu>

2003\07\10@164823 by Alex Kilpatrick

flavicon
face
>
> Obviously, Alex, you're NOT getting out of here alive....
>
> <g>
>
> --Bob

Gah, tell me about it.  :-p  Let me confess all my other sins and get
them out of the way:

1.  I use a compiler, because I think coding in assembler is silly (for
what I need to do, and 99% of what other people need to do)
2.  I often (ok, usually) don't comment my code
3.  I don't own an oscilloscope (although I do own a logic analyzer)
4.  I built a project with an external crystal for a real-time clock,
and I didn't use external capacitors
5.  I don't use decoupling capacitors on my breadboard experiments
6.  I don't know resistor color codes by heart.  I have a gadget from
Radio Shack that tells them to me
7.  I once built a PIC project that ran at 6.5 V, without a voltage
regulator
8.  I interface with the serial port without a MAX232 chip
9.  I heat up my PCB developer solution, even though you are not
supposed to
10. I don't use a diode on MCLR

There may be more, but that is all I can think of now.  If you guys want
to kick me off the piclist, I'll understand....


Alex

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestspamspammitvma.mit.edu>

2003\07\10@165651 by Bob Axtell

face picon face
No way  Alex! Don't leave. You're in learning mode. More below..

At 03:48 PM 7/10/2003 -0500, you wrote:
> >
> > Obviously, Alex, you're NOT getting out of here alive....
> >
> > <g>
> >
> > --Bob
>
>Gah, tell me about it.  :-p  Let me confess all my other sins and get
>them out of the way:
>
>1.  I use a compiler, because I think coding in assembler is silly (for
>what I need to do, and 99% of what other people need to do)

That's OK. Who cares? _I_ don't. But I personally don't use higher-level
languages myself, for what I do, ASM is required.

>2.  I often (ok, usually) don't comment my code

You need to start.

>3.  I don't own an oscilloscope (although I do own a logic analyzer)

Just buy a used one from military surplus.

>4.  I built a project with an external crystal for a real-time clock,
>and I didn't use external capacitors

Use ceramic resonators, they have caps built-in.

>5.  I don't use decoupling capacitors on my breadboard experiments

Now, you're a lucky guy. Would you be available for a trip to LasVegas with me?

>6.  I don't know resistor color codes by heart.  I have a gadget from
>Radio Shack that tells them to me

I'm colorblind. I have to ask my wife what the colors are. SHE uses the
gadget from Radio Shack.

>7.  I once built a PIC project that ran at 6.5 V, without a voltage
>regulator

Me, too! It worked, too.

>8.  I interface with the serial port without a MAX232 chip

Well it works on SOME PCs, others, no..

>9.  I heat up my PCB developer solution, even though you are not
>supposed to

I never fuss with the stuff, it stains my fingers.

>10. I don't use a diode on MCLR

I don't either. Never have. Never had a problem, either.

>There may be more, but that is all I can think of now.  If you guys want
>to kick me off the piclist, I'll understand....

Nope, you're a lifer here. Join the rest of us. Ignore the jibes.

--Bob

>Alex
>
>--
>http://www.piclist.com hint: To leave the PICList
>spam_OUTpiclist-unsubscribe-requestspam_OUTspamspam_OUTmitvma.mit.edu

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestspam_OUTspammitvma.mit.edu>

2003\07\10@170901 by Alex Kilpatrick

flavicon
face
>
> No way  Alex! Don't leave. You're in learning mode. More below..
>
Nah, I'm not going anywhere.  This is too much fun.

> >
> >1.  I use a compiler, because I think coding in assembler is
> silly (for
> >what I need to do, and 99% of what other people need to do)
>
> That's OK. Who cares? _I_ don't. But I personally don't use
> higher-level languages myself, for what I do, ASM is required.
>
I hear that a lot, but I am always skeptical.  Since you can use C and
mix in assembler for time-critical parts, I don't know why anyone would
mess with complete assembler.  The code is much more readable and
manageable.

What app are you doing that *has* to have assembler.

>
> >4.  I built a project with an external crystal for a
> real-time clock,
> >and I didn't use external capacitors
>
> Use ceramic resonators, they have caps built-in.
>
This was to drive timer1 to allow the PIC to have a real-time clock, it
wasn't the PIC oscillator because I used the internal one for that.  As
far as I know, there aren't any 32.768K ceramic resonators, and if there
were they wouldn't be as precise as crystal.

> >5.  I don't use decoupling capacitors on my breadboard experiments
>
> Now, you're a lucky guy. Would you be available for a trip to
> LasVegas with me?
>
I have never seen it make any difference.  I have heard that breadboards
have internal capacitance that takes care of it.  I always have too many
wires on a breadboard, and the caps just get in the way.

I do use them on production boards.  I'm not that much of a gambler.

> >6.  I don't know resistor color codes by heart.  I have a
> gadget from
> >Radio Shack that tells them to me
>
> I'm colorblind. I have to ask my wife what the colors are.
> SHE uses the gadget from Radio Shack.
>
You have a forgiving wife.  I think mine would be quite annoyed if I had
to ask her all the time.

You could use a ohm-meter and do the process of elimination.  :-)

>
> Nope, you're a lifer here. Join the rest of us. Ignore the jibes.
>
> --Bob
>
I've been on the internet since the days when we just had 1's, so I'm
fine.

Alex

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestKILLspamspam@spam@mitvma.mit.edu>

2003\07\10@171525 by Dale Botkin

flavicon
face
On Thu, 10 Jul 2003, Alex Kilpatrick wrote:

> 1.  I use a compiler, because I think coding in assembler is silly (for
> what I need to do, and 99% of what other people need to do)
> 2.  I often (ok, usually) don't comment my code
> 3.  I don't own an oscilloscope (although I do own a logic analyzer)
> 4.  I built a project with an external crystal for a real-time clock,
> and I didn't use external capacitors
> 5.  I don't use decoupling capacitors on my breadboard experiments
> 6.  I don't know resistor color codes by heart.  I have a gadget from
> Radio Shack that tells them to me
> 7.  I once built a PIC project that ran at 6.5 V, without a voltage
> regulator
> 8.  I interface with the serial port without a MAX232 chip
> 9.  I heat up my PCB developer solution, even though you are not
> supposed to
> 10. I don't use a diode on MCLR

Omygawd, this guys sounds like...  like...  a HOBBYIST!  <gasp>

> There may be more, but that is all I can think of now.  If you guys want
> to kick me off the piclist, I'll understand....

Oh, yeah, right.  Only professionals allowed here.  No newbies.  Ha!

Dale
--
It's a thankless job, but I've got a lot of Karma to burn off.
Get a PicoKeyer: http://www.hamgadgets.com

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestspamBeGonespam.....mitvma.mit.edu>

2003\07\10@172354 by Olin Lathrop

face picon face
> Gah, tell me about it.  :-p  Let me confess all my other sins and get
> them out of the way:
>
> 1.  I use a compiler, because I think coding in assembler is silly (for
> what I need to do, and 99% of what other people need to do)
> 2.  I often (ok, usually) don't comment my code
> 3.  I don't own an oscilloscope (although I do own a logic analyzer)
> 4.  I built a project with an external crystal for a real-time clock,
> and I didn't use external capacitors
> 5.  I don't use decoupling capacitors on my breadboard experiments
> 6.  I don't know resistor color codes by heart.  I have a gadget from
> Radio Shack that tells them to me
> 7.  I once built a PIC project that ran at 6.5 V, without a voltage
> regulator
> 8.  I interface with the serial port without a MAX232 chip
> 9.  I heat up my PCB developer solution, even though you are not
> supposed to
> 10. I don't use a diode on MCLR

Some of this is funny, but don't you think it's only common courtesy to
have done all the reasonable and accessible things to avoid stupid
mistakes before asking 2000 people for a favor to help diagnose your
problem?


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: To leave the PICList
KILLspampiclist-unsubscribe-requestspam.....mitvma.mit.edu>

2003\07\10@191333 by Rick Regan

picon face
> > >5.  I don't use decoupling capacitors on my
> breadboard experiments
> >
> > Now, you're a lucky guy. Would you be available
> for a trip to
> > LasVegas with me?
> >
>
> I have never seen it make any difference.  I have
> heard that breadboards
> have internal capacitance that takes care of it.  I
> always have too many
> wires on a breadboard, and the caps just get in the
> way.
>

In Myke Predko's PIC book he has an experiment called
'decouple' where he turns a bunch of LEDs on and off
rapidly to show the value of decoupling caps.  With
the caps it works fine; without them the PIC resets (I
tried the experiment on a breadboard by the way).

__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

--
http://www.piclist.com hint: To leave the PICList
spam_OUTpiclist-unsubscribe-requestspamKILLspammitvma.mit.edu>

2003\07\10@203649 by Mike Singer

picon face
Good part of a FAQ for beginners.
Add something about
- casual grounding and shielding;
- long cables with messy wires;
- mains wires among others on the same connector (symmetrical
 connector without key, of course);
- 0.125W resistor in place of 1W one;
- severe overclocking;
- do first then think;
- reading datasheets - what a stupid business;
...

Mike.



Alex Kilpatrick wrote:
------------------------------------------
Gah, tell me about it.  :-p  Let me confess all my other sins and get
them out of the way:

1.  I use a compiler, because I think coding in assembler is silly (for
what I need to do, and 99% of what other people need to do)
2.  I often (ok, usually) don't comment my code
3.  I don't own an oscilloscope (although I do own a logic analyzer)
4.  I built a project with an external crystal for a real-time clock,
and I didn't use external capacitors
5.  I don't use decoupling capacitors on my breadboard experiments
6.  I don't know resistor color codes by heart.  I have a gadget from
Radio Shack that tells them to me
7.  I once built a PIC project that ran at 6.5 V, without a voltage
regulator
8.  I interface with the serial port without a MAX232 chip
9.  I heat up my PCB developer solution, even though you are not
supposed to
10. I don't use a diode on MCLR

There may be more, but that is all I can think of now.  If you guys want
to kick me off the piclist, I'll understand....
------------------------------------

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestRemoveMEspamEraseMEmitvma.mit.edu>

2003\07\10@215633 by Dkbovaird

picon face
In some cases, if you're lucky, messy wires and breadboard circuit layouts
can work in your favor, sometimes wires and parts not so close together or in an
ordered relationship could lead to reduced coupling and crosstalk. Sometimes
things work fine on a breadboard but fail when converted to a PCB.
Sometimes...

I'm a firm believer in filter caps though. I haven't heard a convincing
argument yet about the dangers of over filtering a board. Real estate is never so
tight that I can't at least try to squeeze in a cap here or there.

dave.

In a message dated 7/10/03 5:37:38 PM Pacific Daylight Time,
KILLspammsingerspamspamBeGonePOLUOSTROV.NET writes:

> Good part of a FAQ for beginners.
> Add something about
> - casual grounding and shielding;
> - long cables with messy wires;
>


--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestspamspammitvma.mit.edu>

2003\07\10@232959 by Bob Axtell

face picon face
Well-said, Dave.

Years ago I always breadboarded  everything with wire-wrap sockets. But
stopped when I discovered that the PCB that resulted just didn't work the same.

It has been easier and less costly for me to actually lay out a working
breadboard that is close to the right size and form factor, get it all
working, maybe even do a 2nd breadboard, before committing to a final layout.

--Bob


At 09:56 PM 7/10/2003 -0400, you wrote:
{Quote hidden}

---------------
NOTICE

1. This account can accept email & attachments up to 10M in size.
2. Federal Monitors: At request of client, some attachments are encrypted.
Please DO NOT delay traffic; please reply with credentials for password.
--------------

--
http://www.piclist.com hint: To leave the PICList
@spam@piclist-unsubscribe-requestSTOPspamspam@spam@mitvma.mit.edu>

2003\07\11@042516 by Alan B. Pearce

face picon face
>>1.  I use a compiler, because I think coding in assembler is silly
>>(for what I need to do, and 99% of what other people need to do)
>
>That's OK. Who cares? _I_ don't. But I personally don't use
>higher-level languages myself, for what I do, ASM is required.

Well that is a case of horses for courses - use what is best for the job.


>>2.  I often (ok, usually) don't comment my code
>
>You need to start.

Agreed. Commenting is most important when you get to the debugging stage,
especially if you need to come back later to alter something.


>>3.  I don't own an oscilloscope (although I do own a logic analyzer)
>
>Just buy a used one from military surplus.

Or ebay. I suspect that having an oscilloscope available would have helped
solve this particular problem by now.


>>4.  I built a project with an external crystal for a real-time clock,
>>and I didn't use external capacitors
>
>Use ceramic resonators, they have caps built-in.

Depending on the accuracy you need, you might get away without caps. But
don't come crying to us when the oscillator does not work. These things are
specified for a reason. As some of the contributors on this list point out,
they are not here to help when you do silly things outside of specification.


>>5.  I don't use decoupling capacitors on my breadboard experiments
>
>Now, you're a lucky guy. Would you be available for a trip to LasVegas with
me?

again this is just plain silly. There are good sound reasons for using
these. If you do not use them then how do you expect your breadboard to be
useable?


>>6.  I don't know resistor color codes by heart.  I have a gadget from
>>Radio Shack that tells them to me
>
>I'm colorblind. I have to ask my wife what the colors are. SHE uses the
>gadget from Radio Shack.

Or use a DMM - but this project is SMT, and SMT resistors do not use colour
codes (unless you use those horrible mini-melf ones that roll off the PCB
before you can solder them). The ones I have a problem with are the space
certified ones which are not marked for value, or ceramic capacitors which
no manufacturer seems to mark for value for some unknown reason.


>>7.  I once built a PIC project that ran at 6.5 V, without a voltage
>>regulator
>
>Me, too! It worked, too.

But be prepared to let the magic smoke out :))


>>8.  I interface with the serial port without a MAX232 chip
>
>Well it works on SOME PCs, others, no..

Can be done with suitable precautions, but again you need to know what your
doing and why.


>>9.  I heat up my PCB developer solution, even though you are not
>>supposed to
>
>I never fuss with the stuff, it stains my fingers.

I find it just as easy to get prototype ones made by a board house - saves
all the hassles of quality, plated through holes - and provides pads for
bypass capacitors.


>>10. I don't use a diode on MCLR
>
>I don't either. Never have. Never had a problem, either.
>
>There may be more, but that is all I can think of now.  If you guys want
>to kick me off the piclist, I'll understand....

You would be better off getting the idiosyncrasies sorted to get the project
back on track.

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

2003\07\11@042525 by Mike Singer

picon face
Dkbovaird@AOL.COM wrote:
> In some cases, if you're lucky, messy wires and breadboard
> circuit layouts can work in your favor, sometimes wires and
> parts not so close together or in an ordered relationship
> could lead to reduced coupling and crosstalk.
> Sometimes things work fine on a breadboard but fail when
> converted to a PCB. Sometimes...

If you understand what are you doing, there should not be
"sometimes" surprises.

If you don't, the best advice I've found on PICList is Olin's
about the Moon and a fish :-)

I don't like any surprises in my work, any.

Mike.

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

2003\07\11@043245 by Nigel Orr

flavicon
face
pic microcontroller discussion list <> wrote on Thursday, July 10, 2003
7:29 PM:

> Yes, I never planned to get this much discussion.  I feel like I am
> on trial now.  :-)

Not on trial, everyone makes mistakes, experience teaches you how to find
them.  If you don't want experience, don't ask questions, just stumble on
and ignore the bugs.  Several of us have made a fair effort in helping you
to debug at a distance, assuming that you wanted to take some time to solve
the problem(s).  We're not out to judge you (but if your design was
something like a cardiac defibrillator or car engine management, I'd love
to know what the brand name is going to be, to try to avoid it if 1 out of
2 might or might not work :-) :-) :-) :-) )

Obviously there is some fault making your design crash in the first place,
and another problem when it resets afterwards.  If you don't care about
that, then that's a shame, but it would be nice to let us know that it's
not worth wasting our time on.

But it _is_ worth pursuing the fault, honestly, in your own time.
Electronics can be very discouraging without a good ability to hunt down
faults.  You will learn a lot from it, and your next design will be better.
It's rare that I go hunting for a fault without finding at least one other,
more subtle, problem before tracking down the one I was looking for.  And
it's the subtle problems that you want to find _before_ they start causing
symptoms.

Perhaps if you find why your code is crashing, the reason for the apparent
MCLR problem will be obvious.  If it is, please let us know, then next time
I or somebody else has the same symptoms, it will be in the archives.

(And if only one board is crashing in the first place, I'd be trying
different batteries/dc power supplies, and metering every pin to it's
adjacent pins looking for solder whiskers.  As you aren't that interested
in finding the fault, that's my final suggestion, best of luck :-) )

Nigel
--
Nigel Orr, Design Engineer                 nigelspamBeGonespamspamBeGoneaxoninstruments.co.uk
Axon Instruments Ltd., Wardes Road,Inverurie,Aberdeenshire,UK,AB51 3TT
              Tel:+44 1467 622332 Fax:+44 1467 625235
                  http://www.axoninstruments.co.uk

2003\07\11@044526 by Nigel Orr

flavicon
face
> 1.  I use a compiler, because I think coding in assembler is
> silly (for what I need to do, and 99% of what other people need to do)

For trivial projects (under a few hundred bytes), and with a decent set of
library routines, I usually do assembler (eg my almost-finished ultrasonic
depth measurer!).  Anything bigger, that needs to squeeze in a tight space
or time is usually written in C, and I check the assembler output for the
critical section to see, for example, whether it is best to use:
       x=(a?b:c)
       if a x=b else x=c
or      switch(value) case (a):
because different compilers have different ideas about that!

If it gets really desperate, and I can't convince the compiler of the fast
way to do it, I do inline assembler.  When speed or time doesn't matter
much, and the code passes all tests, I stick to C.

> 5.  I don't use decoupling capacitors on my breadboard experiments

...which could be at least part of the problem(s) you are having.

> 6.  I don't know resistor color codes by heart.  I have a gadget from
> Radio Shack that tells them to me

I know the colours, but with a mixture of different brands of resistor, the
meter is usually the fastest way to figure it out.  One advantage of SMD
resistors is that the value is easier to read!

> 8.  I interface with the serial port without a MAX232 chip

I have to trump you on that, I sometimes interface the serial port by
connecting PIC +5V to serial port GND and PIC TX to serial RX, just to get
a quick debug output from a misbehaving PIC without adding transistors
etc... the PIC supply does have to be isolated from the PC supply, it does
preclude using earthed probes on the circuit at the same time, and
obviously only works on some PCs, all in all a horrible bodge, not to be
recommended!  But they say confession is good for the soul :-)

Nigel
--
Nigel Orr, Design Engineer                 spamBeGonenigelspamaxoninstruments.co.uk
Axon Instruments Ltd., Wardes Road,Inverurie,Aberdeenshire,UK,AB51 3TT
              Tel:+44 1467 622332 Fax:+44 1467 625235
                  http://www.axoninstruments.co.uk

2003\07\11@051051 by Jinx

face picon face
> > 8.  I interface with the serial port without a MAX232 chip
>
> I have to trump you on that, I sometimes interface the serial port by
> connecting PIC +5V to serial port GND and PIC TX to serial RX

Make a small board with a MAX232 + caps on it, PC serial lead
and clips to attach to the PIC. Comes in very handy to download
or upload RAM / EEPROM during debugging

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

2003\07\11@052954 by Jinx

face picon face
> I hear that a lot, but I am always skeptical.  Since you can use C and
> mix in assembler for time-critical parts, I don't know why anyone would
> mess with complete assembler.  The code is much more readable and
> manageable.

If you structure your code properly and COMMENT it, assembler can
be perfectly readable and manageable. You can use macros, includes,
definitions, subroutines, and labels galore to help

Try "messing" with a Scenix to manage individual 20ns cycle times in
time-critical (very) applications without using assembler throughout

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

2003\07\11@063542 by Nigel Orr

flavicon
face
> > I have to trump you on that, I sometimes interface the
> serial port by
> > connecting PIC +5V to serial port GND and PIC TX to serial RX
>
> Make a small board with a MAX232 + caps on it, PC serial lead
> and clips to attach to the PIC. Comes in very handy to download
> or upload RAM / EEPROM during debugging

I know, I know... I was just trying to reassure Alex that he's not the only
one with electronic skeletons in the closet!

I've got a board as you describe (but without the clips, that's a good
idea), and we have several of them floating around at work, laziness
sometimes overrules logic for a 'quick check' at home though!

Nigel
--
Nigel Orr, Design Engineer                 spam_OUTnigelSTOPspamspamaxoninstruments.co.uk
Axon Instruments Ltd., Wardes Road,Inverurie,Aberdeenshire,UK,AB51 3TT
              Tel:+44 1467 622332 Fax:+44 1467 625235
                  http://www.axoninstruments.co.uk

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

2003\07\11@084736 by Alex Kilpatrick

flavicon
face
>
> Some of this is funny, but don't you think it's only common
> courtesy to have done all the reasonable and accessible
> things to avoid stupid mistakes before asking 2000 people for
> a favor to help diagnose your problem?
>
Of course.  But I know the symptoms of these things, and if I ever see
them, then I go back to the "safe" mode.

I would never say "Oh, my PIC is resetting randomly.  What's wrong?"
when I knew that I wasn't using bypass caps.

Alex

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

2003\07\11@090856 by Alex Kilpatrick

flavicon
face
>
> Obviously there is some fault making your design crash in the
> first place, and another problem when it resets afterwards.  
> If you don't care about that, then that's a shame, but it
> would be nice to let us know that it's not worth wasting our time on.
>
I do care about it.  But since the second board works, I know it is not
a problem with the design.  My design is not crashing, a particular
implementation of the design is crashing.

> But it _is_ worth pursuing the fault, honestly, in your own
> time. Electronics can be very discouraging without a good
> ability to hunt down faults.  You will learn a lot from it,
> and your next design will be better. It's rare that I go
> hunting for a fault without finding at least one other, more
> subtle, problem before tracking down the one I was looking
> for.  And it's the subtle problems that you want to find
> _before_ they start causing symptoms.
>
I agree completely.  But this would have to be in my own time, which
means I'm not getting paid for it.  I'm already overtime on this project
(meaning I am getting paid less and less per hour) and my customer only
cares about getting working prototypes (these are research proofs of
concept, not commercial products).  Sometimes when you get crunched for
time, you are just happy to get something working.  In the back of your
mind you day "later, I need to go back and investigate that further."
Sometimes you do, sometimes you don't.

I actually do software professionally.  I am always happy when I find
something that doesn't work as expected, because it means that my mental
model is wrong.  That's where all the real learning occurs.

>
> (And if only one board is crashing in the first place, I'd be
> trying different batteries/dc power supplies, and metering
> every pin to it's adjacent pins looking for solder whiskers.  
> As you aren't that interested in finding the fault, that's my
> final suggestion, best of luck :-) )
>
I will definitely investigate this one further, if for no other reason
than to completely close out this discussion.  Unfortunately, I am on
travel right now, so my tools are pretty limited.  :-)

Alex

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

2003\07\11@095719 by Olin Lathrop

face picon face
> Of course.  But I know the symptoms of these things,

I don't think anyone can "know" the symptoms of neglecting some of these
practises.  Missing bypass caps, for example, can cause bizzarre flaky
operation in seemingly unrelated parts of the circuit.  Poor code
documentation invites things like bank setting errors which also have no
reliable symptoms.

Look, you're the one that came to us with a problem.  Obviously there is
*something* wrong, and furthermore you obviously don't know what it is.
The problem seems to be that you don't know what you don't know, and
aren't willing to learn.  I see you've been given a lot of good advice
from people that clearly know a lot more about electronics and PICs than
you do, but you turn around and argue that it's irrelevant instead of
heading it.  You don't have to take others' advice, but if you're not
willing to accept any of it, please stop wasting everyone's time asking
for it.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

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

2003\07\11@102354 by Olin Lathrop

face picon face
Alex Kilpatrick wrote:
> I do care about it.  But since the second board works, I know it is not
> a problem with the design.  My design is not crashing, a particular
> implementation of the design is crashing.

Argh!!!  Once again you are missing the point.  There is no way you can
"know it is not a problem with the design".  Apparently 1 out of 3 boards
doesn't work.  That doesn't prove the design to me.  There are many ways a
bad design can appear to work 2 out of 3 times, but since you already have
your mind made up that your design is correct, there is no point in my
explaining how this is possible.

> I agree completely.  But this would have to be in my own time, which
> means I'm not getting paid for it.

You are getting paid to do this!!?  From your attitude, I thought this was
a hobby project.  Frankly, you should be ashamed of yourself and consider
a different line of work.  You have a certain responsibility to a customer
when you take money.  Fortunately for you there isn't such a thing as
malpractise for consultants, but sometimes I think there should be.

> I'm already overtime on this project
> (meaning I am getting paid less and less per hour)

Yeah, so?  Apparently you agreed to produce a design and some units for a
fixed price.  That's fine, but it also means you've accepted any
responsibility for unforseen problems.  Cutting corners because you are
over budget is completely irresponsible.  Perhaps you didn't price it
right.  Perhaps you overestimated your capabilities.  Perhaps you didn't
start with a tight spec and allowed additional features to creep in for
the same price.  It doesn't matter.  You either need to do whatever it
takes to deliver what you promised using accepted professional practises,
or go to your customer in shame and tell them you can't do it and refund
EVERY PENNY they've paid you.

You're attitude is a disgrace to all professional engineers.

> and my customer only
> cares about getting working prototypes

As they should, since that's apparently what they are paying for.

> (these are research proofs of
> concept, not commercial products).  Sometimes when you get crunched for
> time, you are just happy to get something working.  In the back of your
> mind you day "later, I need to go back and investigate that further."

This is just too much!  I was going to comment about duty to deliver a
professional product, but on second thought I don't think you'd
understand.

Any additional discussion is pointless.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

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

2003\07\11@102815 by Alex Kilpatrick

flavicon
face
> Look, you're the one that came to us with a problem.  
> Obviously there is
> *something* wrong, and furthermore you obviously don't know
> what it is. The problem seems to be that you don't know what
> you don't know, and aren't willing to learn.  I see you've
> been given a lot of good advice from people that clearly know
> a lot more about electronics and PICs than you do, but you
> turn around and argue that it's irrelevant instead of heading
> it.  You don't have to take others' advice, but if you're not
> willing to accept any of it, please stop wasting everyone's
> time asking for it.
>
I have received lots of good advice from the PICLIST on a variety of
topics.  And I am truly grateful to all who responded to my questions.
If I have come across as not appreciating this advice, then I apologize.


However, all I have gotten from you, Olin is a condescending attitude,
so please feel free not to waste your time responding to me, because I
don't need to hear from you.

Alex

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

2003\07\11@104032 by Alex Kilpatrick

flavicon
face
> > I agree completely.  But this would have to be in my own
> time, which
> > means I'm not getting paid for it.
>
> You are getting paid to do this!!?  From your attitude, I
> thought this was a hobby project.  Frankly, you should be
> ashamed of yourself and consider a different line of work.  
> You have a certain responsibility to a customer when you take
> money.  Fortunately for you there isn't such a thing as
> malpractise for consultants, but sometimes I think there should be.
>
Just to clear this up, my customer knows fully well that this is my
hobby.  I do other work for them, and I went to them and said "PICs are
my hobby, but I think I can build something useful for our project"
They have been perfectly happy with the results and the arrangement.

>
> This is just too much!  I was going to comment about duty to
> deliver a professional product, but on second thought I don't
> think you'd understand.
>
As I said, it is not a professional product.  It is a proof of concept.
If it works long enough for a demonstration, that is good enough.
Putting more into it than it needs is a waste of money.

> Any additional discussion is pointless.
>
Definitely.

Alex

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

2003\07\11@132721 by Dkbovaird

picon face
I read up to this point and I thought "aha, a software guy" and later Alex
confirmed that.

I'd categorize myself as a hardware guy and most software people I talk with
seem to think that if software works once then it will always work, otherwise
it's a "hardware" problem. I've been burned too many times by registers not
being initialized quite correctly so that I don't just jump in and start looking
for something wrong in the hardware. Separate ivory towers for the two
disciplines makes problem solving more difficult.

dave.


In a message dated 7/11/03 6:09:44 AM Pacific Daylight Time,
RemoveMEAlexKspamspamHCITRAINING.COM writes:

> I do care about it.  But since the second board works, I know it is not
> a problem with the design.  My design is not crashing, a particular
> implementation of the design is crashing.


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

2003\07\11@142259 by Barry Gershenfeld

face picon face
>I'm a firm believer in filter caps though. I haven't heard
> a convincing argument yet about the dangers of over filtering
> a board.
>dave.

I don't know if I will convince you, but we are repeately dealing
with power supply parts that will not come up due to the inrush
current of the board.  The power supply has overcurrent protection.
The worst is a computer motherboard.  Some of the power components
have a "soft start" feature that lets you ramp up slowly.  But the
spec for ATX power supplies has a minimum risetime spec...

I guess there just is no free lunch.

Barry

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

2003\07\11@142435 by Alex Kilpatrick

flavicon
face
>
> I read up to this point and I thought "aha, a software guy"
> and later Alex confirmed that.
>
Yep.  Actually, I am a computer engineer, which is supposed to cover
both disciplines.  But all the good money is in software, so that is
where I have spend 99% of my time.  Most of my work is in .NET, Java,
and Lisp if anyone is interested.  My background is in machine learning.

> I'd categorize myself as a hardware guy and most software
> people I talk with seem to think that if software works once
> then it will always work, otherwise it's a "hardware"
> problem. I've been burned too many times by registers not
> being initialized quite correctly so that I don't just jump
> in and start looking for something wrong in the hardware.
> Separate ivory towers for the two disciplines makes problem
> solving more difficult.
>
Most software people are accustomed to not thinking of hardware at all.
All the computer science people I know consider it "beneath" them to
even consider hardware.  They like to think of their code as running on
some abstract machine that always works the same way.  I have never
heard a developer even consider the fact that something could be wrong
with the hardware.  Sometimes they blame the OS or some high level
library, when the problem is typically in their code.

In my case I am doing both the hardware and software (as are most of
us).  My approach when I have a bug is to drop the software back to the
simplist thing possible, which is usually a blinking LED.  If I still
have a problem with a blinking LED, then I tend to think the problem is
hardware.  I think that's reasonable.  Let me go on the record here,
though, as saying that the very *last* thing I would blame is the PIC or
some other established component.  For me to blame the hardware, it
would be either my crappy soldering, or something I left off the circuit
(things like decoupling caps, etc.)


Alex

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

2003\07\11@151222 by Olin Lathrop

face picon face
> I don't know if I will convince you, but we are repeately dealing
> with power supply parts that will not come up due to the inrush
> current of the board.  The power supply has overcurrent protection.
> The worst is a computer motherboard.  Some of the power components
> have a "soft start" feature that lets you ramp up slowly.  But the
> spec for ATX power supplies has a minimum risetime spec...

Also, some DC-DC converter modules have a maximum output capacitance spec.
In one case where we were cleaning up a design after Vinny, the output of
a DC-DC converter would not come up right reliably.  It had 100uF on its
output, and it worked when I took off enough caps to bring it below the
47uF maximum specified by the manufacturer.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

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

2003\07\11@163212 by David Minkler

flavicon
face
Alex Kilpatrick wrote:
> For me to blame the hardware, it would be either my crappy
> soldering, or something I left off the circuit (things like
> decoupling caps, etc.)


It is worth reading the errata however.  We found at least one
(confirmed by Microchip, errata then issued) silicon flaw.  I guess,
that's why there are errata.

Best regards,

Dave Minkler

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

2003\07\11@210225 by Alex Kilpatrick

flavicon
face
>
> Alex Kilpatrick wrote:
> > For me to blame the hardware, it would be either my crappy
>  > soldering, or something I left off the circuit (things
> like  > decoupling caps, etc.)
>
>
> It is worth reading the errata however.  We found at least
> one (confirmed by Microchip, errata then issued) silicon
> flaw.  I guess, that's why there are errata.
>
I knew it!  That is probably the source of all my problems!  :-)

What was the flaw?  I'm curious.  I imagine it was probably something
that doesn't come up very often.  I'm sure Microchip has some pretty
extensive test suites.

Alex

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

2003\07\12@021557 by Dkbovaird

picon face
Ok, I'll concede the point with regards to ramp up specs and total output
capacitance loads on DC-DC converters. Usually (in my case) DC-DC converters are
for local supply of one or two components and of course with any new parts I
use in a new design I'll go through the device spec pretty throughly (or try
to) before the schematic is ever drawn (or finalized).

I was really referring more to high frequency bypass caps rather than low
freq. bulk capacitors.

I'll be sure to watch my words more closely in the future, boy, there's
always one (or in this lists case, several) in every crowd. I had a feeling once I
got up on that soapbox I'd regret it. : ) <- smiley face?

dave.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\07\14@135113 by David Minkler

flavicon
face
Alex,

I don't know how extensive the flaw is/was but we observed it on 18F252s.

There are a few instructions which require two memory words rather than
the usual one (byte to byte, Call/Goto/Branch).  If an asynchronous
interrupt occurs during the read of the first word, the processor jumps
to the ISR and doesn't handle the second word correctly on return.

You are correct, it doesn't happen very often but it does happen.
Microchip was very responsive once we were able to point them to exactly
when the problem occurs.  Don't know if the silicon has been fixed or
not.  We just bracket all of these instructions with disable/re-enable
interrupts.  Kind of a pain (especially for compiler manufacturers -
even more so for programmers who work exclusively with higher level
languages who are unaware of the problem) but workable.

Dave

Alex Kilpatrick wrote:

> What was the flaw?  I'm curious.  I imagine it was probably something
> that doesn't come up very often.  I'm sure Microchip has some pretty
> extensive test suites.

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

2003\07\14@142357 by Alex Kilpatrick

flavicon
face
>
> Alex,
>
> I don't know how extensive the flaw is/was but we observed it
> on 18F252s.
>
> There are a few instructions which require two memory words
> rather than the usual one (byte to byte, Call/Goto/Branch).  
> If an asynchronous interrupt occurs during the read of the
> first word, the processor jumps to the ISR and doesn't handle
> the second word correctly on return.
>
That sounds like a huge flaw to me.  So, if I have an interrupt during a
branch, then the branch doesn't work correctly?

Yikes!

Alex

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

2003\07\14@143148 by Joyce, Patrick

flavicon
face
Dave,

Is that the same flaw as in the errata sheet regarding high and low priority
interrupts?

"Module: Interrupts
Under certain conditions, the use of dual priority
interrupts may cause a program instruction to
skipped entirely. This has only been observed
when both of the following apply:
* Both high and low interrupts are enabled, and
* A high priority asynchronous interrupt occurs
in the following cycle after any low priority
interrupt.
The event causes the stack to get pushed twice,
and will eventually result in an overflow."

Pat



{Original Message removed}

2003\07\14@145037 by Olin Lathrop

face picon face
> That sounds like a huge flaw to me.  So, if I have an interrupt during a
> branch, then the branch doesn't work correctly?

I remember early versions had this bug, but I thought that was fixed a
long time ago.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

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

2003\07\14@145237 by Olin Lathrop

face picon face
> Is that the same flaw as in the errata sheet regarding high and low
> priority interrupts?
>
> "Module: Interrupts
> Under certain conditions, the use of dual priority
> interrupts may cause a program instruction to
> skipped entirely. This has only been observed
> when both of the following apply:
> * Both high and low interrupts are enabled, and
> * A high priority asynchronous interrupt occurs
> in the following cycle after any low priority
> interrupt.
> The event causes the stack to get pushed twice,
> and will eventually result in an overflow."

No, this is a different bug.  This bug wasn't fixed until rev C0 silicon.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

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

2003\07\14@173716 by David Minkler

flavicon
face
Alex,

I've just gotten clarification from the guy who found the problem.  For
most it's even rarer.  The problem is as described but only for program
memory reads (the TBLRDxx instructions).  We found the problem on
18C252s.  We don't know if the problem appears in the 18F252s.  The
bracketing interrupt disable/re-enable instructions don't hurt anything
(except execution speed/program memory consumption) so we just left them
in when we migrated from the C parts to the F parts and didn't go back
and check to see if they were still needed.  I don't find the issue
mentioned in the current errata but I may not be looking for the right
phrases.

Dave

Alex Kilpatrick wrote:
{Quote hidden}

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

2003\07\17@041851 by Eric Bohlman

picon face
7/11/03 8:07:36 AM, Alex Kilpatrick <EraseMEAlexKRemoveMEspamHCITRAINING.COM> wrote:

>I do care about it.  But since the second board works, I know it is not
>a problem with the design.  My design is not crashing, a particular
>implementation of the design is crashing.

That doesn't follow.  It's entirely possible that something about your design causes it to work
under very narrow, "ideal" conditions but fail when certain hidden assumptions aren't met.  A
correct design works *all the time* under the conditions that *you explicitly specify*; it doesn't
rely on any parameters that are just taken for granted.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\07\17@102545 by Alex Kilpatrick

flavicon
face
>
>
> 7/11/03 8:07:36 AM, Alex Kilpatrick <spamAlexK.....spamspamHCITRAINING.COM> wrote:
>
> >I do care about it.  But since the second board works, I
> know it is not
> >a problem with the design.  My design is not crashing, a particular
> >implementation of the design is crashing.
>
> That doesn't follow.  It's entirely possible that something
> about your design causes it to work under very narrow,
> "ideal" conditions but fail when certain hidden assumptions
> aren't met.  A correct design works *all the time* under the
> conditions that *you explicitly specify*; it doesn't rely on
> any parameters that are just taken for granted.
>
OK, maybe "I know it is not a problem with my design" is too strong of a
statement.  "I have more evidence that it is not a problem with my
design" is more appropriate.

But you say a correct design works "all the time" under conditions that
I explicitly specify.  For the purposes of the demos that I am going to
do, those conditions are:

1)  Connected to my laptop
2)  Using my cables
3)  In the conference room
4)  With a brand new battery
5)  With me running the demo, and no you can't touch it until I am done
with the demo

Obviously, these are pretty ideal specifications.  In fact, I found out
that a regular serial cable is much more noisy than a USB to serial
cable during a recent demo.  
Testing takes time.  The more general your specifications, the more
testing you have to do.  You can trade off those two things to get the
level of reliability you want.  It isn't a binary thing.  If I told my
client that I had tested the device enough to have confidence that it
will work in a 100 degree temperature range, with ten different kinds of
power supplies, in five different levels of EMI, they would slap me on
the wrist for wasting time with that stuff.

I will certainly concede that there are good design things that take
essentially zero resources (like adding decoupling caps), and I do all
of those things that I know about.

Alex

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

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