Searching \ for '[PIC] PIC18F6410 start-up problems...' 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=18F
Search entire site for: 'PIC18F6410 start-up problems...'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] PIC18F6410 start-up problems...'
2009\06\03@222829 by Jesse Lackey

flavicon
face
....just a shout-out to see if I'm doing something dumb.

I have a design with the PIC18F6410, and I can get it to program, but
not start running.  At all, ever.  Not with xtal, or internal RC.

I haven't used the 6410 before, and it could be a problem with the CCS
compiler (my copy is 2 years old - the chip is supported, but that
doesn't mean it works).  CCS seems to be setting the config bits
properly.  I can check/set them in MPLAB.  No help.

The footprint and specs (as far as voltages / xtal go, anyway) look to
be the same as the 6520, which I have used in a half dozen designs.

I'm using MPLAB 8.3.  I have MCLR/ pulled up to +5V with a 10K.  The
xtal is a 10Mhz of the same type I've used in other designs.  At
power-on I can see the MCLR/ line rise as normal.  I have decoupling
caps on each pin that gets +5V.  The +5V line has a bulk 220uF cap, and
comes from a DC bench supply.

I can program it all I want, never starts running, no current draw.

I'm trying to use the 6410 to save $3 per chip for the production run,
but am about to drop $70 to digikey overnight more 6520s to save this
underfunded, poorly scheduled project.

Any advice appreciated.  I'm kind of losing my mind right now.

Thanks.
J

2009\06\03@224510 by Bruno L. Albrecht [GMAIL]

picon face
check the proper oscilator configuration and the wdt

 Bruno L. Albrecht
 Eng. da Computação/06
 Falker Automação Agrícola Ltda.
 http://www.falker.com.br



Jesse Lackey escreveu:
{Quote hidden}

>

2009\06\04@002653 by Jesse Lackey

flavicon
face
As a followup.

This ridiculousness is due to the brownout reset.  If enabled, and set
to 4.6V, it will never run on a 5V supply.  If disabled, or enabled and
set to 4.3V or lower, it runs fine.

As far as I can tell this is another undocumented PIC hardware bug that
has caused me to lose half a day and major frustration with a project on
an aggressive timetable.

I welcome any explanation why a PIC running at +5V would ever be locked
up due to brownout.  I can't fathom.

This experimentation was done using the config bits setting in the
latest MPLAB.  The CCS compiler has nothing to do with it.

Argh.  Another reason I use AVRs for all new designs.

J




Jesse Lackey wrote:
{Quote hidden}

2009\06\04@003752 by Xiaofan Chen

face picon face
On Thu, Jun 4, 2009 at 12:27 PM, Jesse Lackey <spam_OUTjsl-mlTakeThisOuTspamcelestialaudio.com> wrote:
> As a followup.
>
> This ridiculousness is due to the brownout reset.  If enabled, and set
> to 4.6V, it will never run on a 5V supply.  If disabled, or enabled and
> set to 4.3V or lower, it runs fine.
>

Measure your power supply then to see if it ever goes down to 4.6V.


--
Xiaofan http://mcuee.blogspot.com

2009\06\04@005412 by Jesse Lackey
flavicon
face
The DC bench supply is flawless, the scope and a DMM agree it is at 5.05V.

The board I used to debug this insanity has only the PIC, a crystal and
a LED to blink on it.  No decoupling caps or anything else.

The original board (with all required caps and other circuitry) with
this problem now works fine, of course, reprogrammed to not have
brownout @ 4.6V.

Done wasting time on this problem!

J


Xiaofan Chen wrote:
{Quote hidden}

2009\06\04@012404 by Xiaofan Chen

face picon face
On Thu, Jun 4, 2009 at 12:52 PM, Jesse Lackey <jsl-mlspamKILLspamcelestialaudio.com> wrote:
> The DC bench supply is flawless, the scope and a DMM agree it is at 5.05V.
>
> The board I used to debug this insanity has only the PIC, a crystal and
> a LED to blink on it.  No decoupling caps or anything else.

No decoupling caps? Kudos for Atmel if AVR can work with that.
Good lucks...

> The original board (with all required caps and other circuitry) with
> this problem now works fine, of course, reprogrammed to not have
> brownout @ 4.6V.
>
> Done wasting time on this problem!
>

You may want to check support.microchip.com for
some support to see if there is a real problem.

--
Xiaofan http://mcuee.blogspot.com

2009\06\04@021422 by Marcel Birthelmer

picon face
On Wed, Jun 3, 2009 at 9:52 PM, Jesse Lackey <.....jsl-mlKILLspamspam.....celestialaudio.com>wrote:

> The DC bench supply is flawless, the scope and a DMM agree it is at 5.05V.
>
> The board I used to debug this insanity has only the PIC, a crystal and
> a LED to blink on it.  No decoupling caps or anything else.
>
> The original board (with all required caps and other circuitry) with
> this problem now works fine, of course, reprogrammed to not have
> brownout @ 4.6V.
>
> Done wasting time on this problem!
>

If you don't have a decoupling cap, in theory a very short transient,
shorter than what your scope can measure, might trigger the brownout reset
as soon as the chip tries to power on.

Granted, your target (non-debug) circuit probably does have the decoupling
caps, so it's not clear why there is an issue there.

Without decoupling caps, I would be worried about unpredictable,
un-reproducible, scratch-your-head-'til-you-get-to-the-gooey-stuff mystery
bugs further down the road, exactly because transient power spikes could
corrupt internal PIC states. It's unlikely, but not impossible.

- Marcel

2009\06\04@022047 by Funny NYPD

picon face
Not just you.
Even Microchip development team can not figure out how to use the PIC18F2550 POR and BOR properly for their PICKit 2 design. So those two features were simply turned off to save a headache.

Funny N.
Au Group Electronics, http://www.AuElectronics.com




________________________________
From: Jesse Lackey <EraseMEjsl-mlspam_OUTspamTakeThisOuTcelestialaudio.com>
To: Microcontroller discussion list - Public. <piclistspamspam_OUTmit.edu>
Sent: Thursday, June 4, 2009 12:27:14 AM
Subject: Re: [PIC] PIC18F6410 start-up problems...

As a followup.

This ridiculousness is due to the brownout reset.  If enabled, and set
to 4.6V, it will never run on a 5V supply.  If disabled, or enabled and
set to 4.3V or lower, it runs fine.

As far as I can tell this is another undocumented PIC hardware bug that
has caused me to lose half a day and major frustration with a project on
an aggressive timetable.

I welcome any explanation why a PIC running at +5V would ever be locked
up due to brownout.  I can't fathom.

This experimentation was done using the config bits setting in the
latest MPLAB.  The CCS compiler has nothing to do with it.

Argh.  Another reason I use AVRs for all new designs.

J




Jesse Lackey wrote:
{Quote hidden}

2009\06\04@023614 by Jesse Lackey

flavicon
face
Just to clarify the test setup, since there is confusion:

The original test board has a 220uF electrolytic bulk cap, and no less
than 5 0.1uF ceramic caps, one for each VDD and one for the analog VDD.
 (There is a small amount of non-PIC circuitry as well.)

The PIC will not run with brownout enabled and set to 4.6V when using a
clean, double-checked-output-voltage with scope and DMM bench supply I
have used every day for 5 years.

After spending an hour and a half running an errand, thinking about it,
and fuming, I came back and made another test board that had just the
PIC, xtal, and a LED to blink.  To keep it as simple as possible, I put
nothing else at all on the board.

I then simplified the code and removed everything I could think of, and
it (board #2) started working.  Moving forward again, I found it was
this brownout issue that was causing all the problems.

I then put code & everything else back the way it was, and verified that
it always runs EXCEPT when brownout is enabled at 4.5V.

I then put the code back on board #1, and saw exactly the same behavior.

This has nothing to do with decoupling caps, DC power supply voltage or
cleanliness thereof.

Since I didn't trust my instincts on this project and client, and let
myself be talked into doing it for significantly below a reasonable
amount of money (after initially dumping it for financial and time
reasons), I'm not going to spend more time following up with Microchip
about it.  When the brownout is set to 4.2V, everything is fine and
works properly, and I don't lose $350 going to a PIC18F6520.

I don't want this thread to turn into a discussion of the
merit/importance of decoupling caps, since there is nothing to discuss:
use them or take a (stupid in almost all cases) risk.

J




Marcel Birthelmer wrote:
{Quote hidden}

2009\06\04@033001 by Jinx

face picon face

> The PIC will not run with brownout enabled and set to 4.6V

There's at least one issue with BOD

http://ww1.microchip.com/downloads/en/DeviceDoc/80206f.pdf

Doesn't appear to explain your problem, although it indicates that
BOD may be flakey

2009\06\04@052757 by Xiaofan Chen

face picon face
On Thu, Jun 4, 2009 at 2:20 PM, Funny NYPD <KILLspamfunnynypdKILLspamspamyahoo.com> wrote:
> Not just you.
> Even Microchip development team can not figure out how to use the
> PIC18F2550 POR and BOR properly for their PICKit 2 design. So those
> two features were simply turned off to save a headache.

Where did you get the information? Care to share?
The BOR features are turned off because of other reasons.


--
Xiaofan http://mcuee.blogspot.com

2009\06\04@053237 by Xiaofan Chen

face picon face
On Thu, Jun 4, 2009 at 2:36 PM, Jesse Lackey <RemoveMEjsl-mlTakeThisOuTspamcelestialaudio.com> wrote:
> Since I didn't trust my instincts on this project and client, and let
> myself be talked into doing it for significantly below a reasonable
> amount of money (after initially dumping it for financial and time
> reasons), I'm not going to spend more time following up with Microchip
> about it.  When the brownout is set to 4.2V, everything is fine and
> works properly, and I don't lose $350 going to a PIC18F6520.
>

I think it is actually not too much efforts to log a support Web ticket.
Maybe indeed this one has a problem and they may be able to
fix it in the next silicon so that in the future you will have less
problems if you are still using PIC.


--
Xiaofan http://mcuee.blogspot.com

2009\06\04@074101 by olin piclist

face picon face
Jesse Lackey wrote:
> I have a design with the PIC18F6410, and I can get it to program, but
> not start running.  At all, ever.  Not with xtal, or internal RC.

LVP enabled with high or floating PGM pin?

Try a very simple program that runs from the internal oscillator and just
toggles a single pin, then work up from there.  Test it in the simulator
first.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\06\04@075434 by olin piclist

face picon face
Jesse Lackey wrote:
> The board I used to debug this insanity has only the PIC, a crystal and
> a LED to blink on it.  No decoupling caps or anything else.

Wait a minute.  No decoupling caps, and you're complaining about Microchip
wasting your time!!?  You just wasted 2000 people's time with this stupidity
and then misleading everyone when asking for help.  Your original message
said

 "I have decoupling caps on each pin that gets +5V.  The +5V line
  has a bulk 220uF cap, and comes from a DC bench supply."

Without decoupling caps the local Vdd voltage could certainly dip below the
brownout threshold briefly on occasion.  The brownout reset circuit kicks
in, which keeps the chip off for 10s of mS, then it gets another glitch
within uS of starting up.  All this gives the impression it never runs.

> The original board (with all required caps and other circuitry) with
> this problem now works fine, of course, reprogrammed to not have
> brownout @ 4.6V.

You probably have a supply glitch problem there too.  Since you didn't
understand why decoupling caps are needed on a debug board, you probably
messed up the power supply design on the real board too.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\06\04@080642 by olin piclist

face picon face
Funny NYPD wrote:
> Not just you.
> Even Microchip development team can not figure out how to use the
> PIC18F2550 POR and BOR properly for their PICKit 2 design. So those two
> features were simply turned off to save a headache.

Both are turned on in my USBProg and it works great.  I just checked, and
brownout reset is set to 4.5V and the powerup timer is enabled.  Unlike the
PICKit 2 however, I didn't cut corners by using the USB power directly.  The
USBProg includes a boost switcher with a linear post regulator that
guarantees a nice clean 5.0V to the PIC.  Of course there are also bypass
caps in the right places with the high frequency loop currents thought
about.  The USBProg and USBProg2 use a 18F2550, just like the PICKit 2.  The
schematics and source code are all open and accessible from
http://www.embedinc.com/products/usbprog.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\06\04@081658 by M.L.

flavicon
face
On Thu, Jun 4, 2009 at 2:36 AM, Jesse Lackey <spamBeGonejsl-mlspamBeGonespamcelestialaudio.com>wrote:

>
>
> I then simplified the code and removed everything I could think of, and
> it (board #2) started working.  Moving forward again, I found it was
> this brownout issue that was causing all the problems.
>


There are a finite number of things that can keep a chip from starting up.
The BOR seems like a primary suspect. 0.4v is not a big dip for a power rail
especially when you consider that VDD has to get into the chip on some very
small wires. We've all done the "I spent hours on this problem and it was
one stupid bit" dance before, most of us don't blame the person who makes
the microcontroller.
-
Martin

2009\06\04@081707 by olin piclist

face picon face
Jesse Lackey wrote:
> This has nothing to do with decoupling caps, DC power supply voltage or
> cleanliness thereof.

Of course it does.  The single most likely explanation is that the real
board also has some power supply glitches causing the brownout reset circuit
to do exactly what it's supposed to do.  You say it has decoupling caps, but
considering your credibility I have no confidence that they are in the right
place, hooked up the right way, really connected, etc.  Improper or failed
decouping cap connections would produce exactly the symptoms you are
reporting.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\06\04@085243 by Michael Rigby-Jones

flavicon
face


> -----Original Message-----
> From: TakeThisOuTpiclist-bouncesEraseMEspamspam_OUTmit.edu [RemoveMEpiclist-bouncesspamTakeThisOuTmit.edu] On
Behalf
> Of Jesse Lackey
> Sent: 04 June 2009 07:37
> To: Microcontroller discussion list - Public.
> Subject: Re: [PIC] PIC18F6410 start-up problems...
>
> Just to clarify the test setup, since there is confusion:
>
> The original test board has a 220uF electrolytic bulk cap, and no less
> than 5 0.1uF ceramic caps, one for each VDD and one for the analog
VDD.
>   (There is a small amount of non-PIC circuitry as well.)
>
> The PIC will not run with brownout enabled and set to 4.6V when using
a
> clean, double-checked-output-voltage with scope and DMM bench supply I
> have used every day for 5 years.

Did you actually check the datasheet?  The "nominal" 4.6v brownout level
could be as high as 4.87v in practice. That gives you just 130mv head
room from your 5v nominal supply...

Sounds like you simply selected an inappropriate brownout voltage,
possibly coupled with small voltage transients on you design.

Regards

Mike

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

2009\06\04@094025 by Alan B. Pearce

face picon face
>Did you actually check the datasheet?  The "nominal" 4.6v
>brownout level could be as high as 4.87v in practice. That
>gives you just 130mv head room from your 5v nominal supply...
>
>Sounds like you simply selected an inappropriate brownout voltage,
>possibly coupled with small voltage transients on you design.

I also wonder when the DVM was last calibrated, that he was using (least
that was my first reaction to his message where he said he had measured the
voltage).

It is all too easy to be using a DVM which doesn't really have the accuracy
(some of the 3 1/2 digit specs are horrible for absolute accuracy), and
assume that it is right, because it has those magic digits on the display.

2009\06\04@100930 by Funny NYPD

picon face
I don't remember exactly where.
When I was communicating with Walter (It is pity he recently left Microchip and PICKit 2 team.) for our BB0703+ design and 3-in-1 mini-lab design, he mentioned some headache on 2550 BOR too.

If I remembered right, the BOR used to be "on" in older PICKit 2 firmware releases. The newer ones got it all turned off.

Not sure about the PICKit 2 old firmware on POR. But I can see it is off on most recent releases.

I have no issue on POR and BOR on all my own PIC based design. It is quite strange.

Funny N.
Au Group Electronics, http://www.AuElectronics.com




________________________________
From: Xiaofan Chen <xiaofancEraseMEspam.....gmail.com>
To: Microcontroller discussion list - Public. <EraseMEpiclistspammit.edu>
Sent: Thursday, June 4, 2009 5:27:56 AM
Subject: Re: [PIC] PIC18F6410 start-up problems...

On Thu, Jun 4, 2009 at 2:20 PM, Funny NYPD <RemoveMEfunnynypdEraseMEspamEraseMEyahoo.com> wrote:
> Not just you.
> Even Microchip development team can not figure out how to use the
> PIC18F2550 POR and BOR properly for their PICKit 2 design. So those
> two features were simply turned off to save a headache.

Where did you get the information? Care to share?
The BOR features are turned off because of other reasons.


--
Xiaofan http://mcuee.blogspot.com

2009\06\04@102650 by Jinx

face picon face
> The PIC will not run with brownout enabled and set to 4.6V
> when using a clean, double-checked-output-voltage with scope
> and DMM bench supply

Have you tried a variable supply on Vcc to test actual BOR voltage ?

> small voltage transients

The PIC should run when Vcc came back up > BOR

2009\06\04@110259 by Michael Rigby-Jones

flavicon
face


> -----Original Message-----
> From: RemoveMEpiclist-bouncesspam_OUTspamKILLspammit.edu [RemoveMEpiclist-bouncesTakeThisOuTspamspammit.edu] On
Behalf
{Quote hidden}

Unless you are right on the threshold and noise is continuously
triggering the BOR!  i.e. PIC starts up, initialisation code starts
running, small glitch caused by changing port state resets PIC.

Regards

Mike

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

2009\06\04@110438 by Philippe Paternotte

flavicon
face
Hi,

Funny NYPD wrote:

> I don't remember exactly where.
> When I was communicating with Walter (It is pity he recently left
> Microchip and PICKit 2 team.) for our BB0703+ design and 3-in-1 mini-
> lab design, he mentioned some headache on 2550 BOR too.
> If I remembered right, the BOR used to be "on" in older PICKit 2
> firmware releases. The newer ones got it all turned off.
> Not sure about the PICKit 2 old firmware on POR. But I can see it is
> off on most recent releases.

Maybe because PicKit2 has a serious voltage drop...
When you request 5.0 V you have 4.45 V on the device.
This is due to the poor design: the generated voltage
comes from USB 5V, then passes through a regulating mosfet
that cannot saturate, then passes through a switching mosfet,
and finally a shottky diode.
If you request 3.3 V you have 3.15 V on the device; that's better
because the first mosfet may regulate correctly.

Regards,
Philippe.
 

{Quote hidden}

>

2009\06\04@112210 by Philippe Paternotte

flavicon
face
Hi,

Jinx wrote:
> The PIC should run when Vcc came back up > BOR

All is said; BOR should not be permanent so there is a real problem.
The device don't like something and latches the BOR condition at
the programmed level. PS transients may do strange things sometimes,
but maybe there is a real silicon bug here - choose one...
 
Best regards,
 
Philippe.




2009\06\04@113844 by Wouter van Ooijen

face picon face
> Maybe because PicKit2 has a serious voltage drop...
> When you request 5.0 V you have 4.45 V on the device.

Only when the USB connector really delivers 5.0V. The lowest voltage an
USB connector can provide according to the USB spec is much lower.

--

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu

2009\06\04@135223 by Funny NYPD

picon face
I don't think the MOSFET will be a big issue, according to the device spec., the voltage drops is minor compare with the voltage drop on diodes.

The issue maybe a out of tolerance resistor on ADC sample circuits:R13 and R26 (on PICKit 2 schematic).

Funny N.
Au Group Electronics, http://www.AuElectronics.com




________________________________
From: Philippe Paternotte <spamBeGoneppaterSTOPspamspamEraseMEsfr.fr>
To: Microcontroller discussion list - Public. <KILLspampiclistspamBeGonespammit.edu>
Sent: Thursday, June 4, 2009 11:03:55 AM
Subject: RE: [PIC] PIC18F6410 start-up problems...

Hi,

Funny NYPD wrote:

> I don't remember exactly where.
> When I was communicating with Walter (It is pity he recently left
> Microchip and PICKit 2 team.) for our BB0703+ design and 3-in-1 mini-
> lab design, he mentioned some headache on 2550 BOR too.
> If I remembered right, the BOR used to be "on" in older PICKit 2
> firmware releases. The newer ones got it all turned off.
> Not sure about the PICKit 2 old firmware on POR. But I can see it is
> off on most recent releases.

Maybe because PicKit2 has a serious voltage drop...
When you request 5.0 V you have 4.45 V on the device.
This is due to the poor design: the generated voltage
comes from USB 5V, then passes through a regulating mosfet
that cannot saturate, then passes through a switching mosfet,
and finally a shottky diode.
If you request 3.3 V you have 3.15 V on the device; that's better
because the first mosfet may regulate correctly.

Regards,
Philippe.


{Quote hidden}

> -

2009\06\04@180112 by Jesse Lackey

flavicon
face
Olin, I'm going to ask that you reread my sequence of posts where I
describe the two test boards as to why, in my opinion, in this case, the
decoupling caps issue is irrelevant.  They ARE on one board, and I
didn't put them on the other just to have something to compare with quickly.

And BOY am I sorry I didn't put them on, b/c it seems that most of
PIClist can't consider anything except that as the issue, even though
they are on the other test board.

Just to put this, and particularly your frankly obnoxious attitude to
rest, I will retest WITH DECOUPLING CAPS ON BOARD #2 TODAY and
experiment a little further.

I would like an explanation of why my credibility is so bad that you
choose to frankly be directly insulting to me.

I don't need to write simple code in a simulator first, as you suggested
in another email.  Seriously Olin, I have 30+ PIC designs in the last 6
years, and a number of non-pic designs in the field.  This has never
come up in any other design or with any other PIC model.  I'm sorry that
I'm not a beginner you can just off the cuff brush off as some dumbass
arrogant newbie.

It may well be something I'm doing.  I will experiment a little more
today.  I'm willing to mea culpa if it is my fault.

After this thread finally dies I will reconsider posting anything to
PIClist since emails with the tone of the below make an already
stressful situation (real world client work behind schedule) worse.
Maybe I should just end the discussion now.



Olin Lathrop wrote:
{Quote hidden}

2009\06\04@181941 by Rolf

flavicon
face
Jesse Lackey wrote:
... snipped.

Hi Jesse.

Please don't let the attitude of one person reflect poorly on all of us.
On the other hand, at one point there was a group of people who decided
that abrasiveness from individuals was acceptable, so, then again, maybe
you should.


For the record, you will not be the first to have left PICList because
of just one opinionated outburst.

Rolf

2009\06\04@190141 by Jinx

face picon face
>> The PIC should run when Vcc came back up > BOR
>
> Unless you are right on the threshold and noise is continuously
> triggering the BOR!  i.e. PIC starts up, initialisation code starts
> running, small glitch caused by changing port state resets PIC.

That would be easily determined with a scope. Don't know how
others would do it, but I'd try a signal generator with adjustable
DC offset as Vcc to find the nature and limits of BOR. That's
assuming the PIC does in fact recover from a BOR reset

2009\06\05@020151 by Jesse Lackey

flavicon
face
and after all this, it no longer fails on either test board.  I had two
other projects on my bench today, so everything got 'torn down and set
up' twice.  so there is no explanation, other than it must be that
something, somewhere, was not what I thought it was and I didn't catch
it with scope, multiple DMMs, and code/config bit fiddling.

is that mea culpa good enough, Olin?

sorry to bother everyone.

End of thread.
J




Jesse Lackey wrote:
{Quote hidden}

2009\06\05@023351 by Russell McMahon

face
flavicon
face
I'm wearing my PICList admin hat.
This is a very rare event.
Please listen.

I've made copies of all the related posts on this thread and read through
them and then searched them for various terms etc to check who said what.
Not something I can afford the time to do at the moment, or something I get
any joy out of doing. This is being done in the hope of averting larger
happenings.

The relatively minor mayhem on this thread is causing larger ripples than it
needs to.
ALL parties who either FEEL confronted or who may be FELT to be being
confrontational need to count to 10 (or 1024) and perhaps start again or
whatever.

To be clear - Olin, you are in that second category (which I'd hope you'd
realise). It doesn't matter if you don't FEEL that that is reasonable. It
doesn't matter if it IS reasonable. Sometimes the ripples can grow beyond
expectation. *Please* listen.

Note carefully that I am NOT an apologist for Olin - I have butted heads
with him onlist on numerous occasions and occasionally discuss 'behaviour'
offlist. I often enough dislike his way of doing things and sometimes find
his behaviour entirely unacceptable. BUT I respect him and want to see
everyone treated fairly. Olin as much as Jesse. And Jesse as much as Olin.

As far as I can see, Olin made only one 'rude' comment.
ie             " ...  but considering your credibility I have no confidence
that ...").
As put it could come across far ruder than necessary.
Possibly even far ruder than intended.
While it was expressed as a factoid it would be very reasonable to read that
as an opinion of Olin's.
Olin's opinions about you (whoever you are) are worth as much or as little
as the value you place on them.
He is NOT entitled to be rude and abusive onlist. Nobody is.
He should certainly (IMHO as ever) put things better in too many cases.
In the above instance he would have done far better if he'd specifically
spelt out the credibility issue (requiring only a few more words) and even
explained the basis of it.
If he'd said something like " ... you initially said the board had
decoupling capacitors, but now you say that it has none ...  credibility
..." then his comment would have been both understandable and have had some
value.

It seems to me, based on what I see on this list, that one comment about a
person's opinion re your credibility is not an utterly major thing -
especially so if they objectively explain why they consider this to be so.
(If you feel that this opining is incorrect then by all means feel free to
opine (without positing the opinion :-) ) that the person concerned is a
jerk and ignore them.

It is helpful if people seeking solutions try to give as clear a picture as
they can of what changes they have made. Failure to do so does waste the
time of people who are trying to help. What was happening was that there had
been inadequate communication of the operating situation. It had not been
made clear that there were TWO devices and that one had full decoupling and
that one didn't. The subsequent comments did not make sense without this
knowledge. This has now been remedied by subsequent explanation. People
(including Olin) could point out that giving inadequate facts is wasting
people's time and confusing them - which is true - BUT it's all too easy to
do this in real world situations and, once done, no amount of beating about
the head is going to make things better.

As far as I can see, all of Olin's other posts have been relevant, accurate
and useful. They have been put in a generally robust manner - increasingly
more robust than I'd thing necessary - but not beyond what seems to be a
reasonable standard (IMHO as ever) based on list guidelines and how others
behave overall. Politer is always nice of course :-).

___________

Fading into technical - but still of some pertinence to the above:

Numerous other comments have been relevant and useful.
Whether they are relevant in this case is as yet unknown, but that's the
nature of problem location. .

Jesse said:
> And BOY am I sorry I didn't put them on, b/c it seems that most of
> PIClist can't consider anything except that as the issue, even though
> they are on the other test board.

As far as I can see only ONE other poster mentioned decoupling capacitors,
and their comments were polite, technically valid and added usefully to the
discussion.

Michael R.J. noted that actual brownout level as per spec sheet may be as
much as 4.87V  -only 130 mV below the nominal level of a 5V bench supply

Others have mentioned the possibility of very small spikes.

The prospect of the extra analog componentry getting in on the act doesn't
seem to have been suggested -

Methods have been suggested re determining the true level at which BOR
operates at.

Microchip MAY be at fault here, but slanging PICs in general or this one
specifically is liable to make it harder to determine the true problem.

Olin's suggestion of running the simplest possible program in the target
setup with BOR etc enabled had/has considerable merit. It doesn't mater how
many projects you have done or how experienced you are - if you have a
problem you have a problem, and eliminating all the confounding factors MAY
help. In this case we don't d\know what the other cit\rcuitry is or whether
it MAY contribute to the problem.

Olins latest decoupling comment, attached to his 'credibility' post, is
worth noting.
 > Improper or failed
 > decouping cap connections would produce exactly
 > the symptoms you are reporting.
Laying aside the question of what a decouping cap is, in situations with a
nominal 130 mV supply voltage headroom, everything needs to be checked
closely.
What is the rise time of Vdd like? Does it exceed BOR enable from startup
timing?

>From what you said, it seems that the 2nd board does not have the analog
circuitry. If it in fact does have - every time you start up does the
associated analog circuitry have the capability to load down Vdd startup?

etc .

_________________


... ?

_________________


Re

> I would like an explanation of why my credibility is so bad that you
> choose to frankly be directly insulting to me.

Better I explain than Olin :-).
Covered above.
I read this to say:

   'You said that all 5V lines had decoupling caps or electrolytics
   Now you say there is NO decoupling.
   The two statements are incompatible.
   I am unable to believe what you are telling me.'

And, the two statements were incompatible.
He was essentially correct.
He put it badly.
We now know WHY the two statements didn't match.
You could probably have done a better job of explaining things.
Life's like that.
We all do it.
Move along ... .

It would be nice if we could all play nicely together.


                  Russell





2009\06\05@044819 by Nicola Perotto

picon face

Russell McMahon wrote:
> It is helpful if people seeking solutions try to give as clear a picture as
> they can of what changes they have made. Failure to do so does waste the
> time of people who are trying to help.
True.
> What was happening was that there had
> been inadequate communication of the operating situation.
SomeOne can learn to read not only the first message but also the
subsequent before replying!
Not to understand this is not to understand how works a mail list :-)



2009\06\05@081543 by olin piclist

face picon face
Jesse Lackey wrote:
> And BOY am I sorry I didn't put them on, b/c it seems that most of
> PIClist can't consider anything except that as the issue,

Because it *IS* a issue.  Without that issue taken care of, it's pointless
to persue other possibilities because the symptoms of no decoupling can be
so varied and unpredictable.

> I would like an explanation of why my credibility is so bad that you
> choose to frankly be directly insulting to me.

Because you refuse to understand or believe the above, but still claim to be
a professional and know what you're doing.  You lost your credibility the
moment you tried the experiment on the test board without a decoupling cap.
You just don't do that, ever.  Even then a "Oops, doh!" from you and it
would have been forgotten.  However, you dug the hole deeper when you then
tried to defend it, and even deeper by getting annoyed that people refused
to see past the missing decoupling.  From your first sentence quoted above,
it seems you still don't get it and are still digging.

> I don't need to write simple code in a simulator first, as you suggested
> in another email.

In light of subsequent developments I agree.  However, I think it was a
reasonable suggestion given the information you made available at the time.
At that time there was yet no mention of brownout detect, and your complaint
was that the chip would not run.  Bringing it up from a simple program that
hopefully does run and adding complexity back one step at a time can be a
useful way to narrow down on why it doesn't run.  In fact, it seems you did
something like this to determine that brownout reset was the cause.  A
simplified version with brownout reset off worked, and the next version with
it on didn't, if I remember right.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\06\05@085429 by M. Adam Davis

face picon face
On Fri, Jun 5, 2009 at 2:31 AM, Russell McMahon<.....apptechspam_OUTspamparadise.net.nz> wrote:
> What was happening was that there had
> been inadequate communication of the operating situation. It had not been
> made clear that there were TWO devices and that one had full decoupling and
> that one didn't.

I'm scratching my head over this one - It was completely clear to me.
Perhaps a few others were skimming, rather than reading the posts.  I
know of at least one regular poster here that chooses to reply to
posts before reading the entire thread (and typically provides useful,
but often redundant and confusing output due to this practice) -
probably due to the way they use their mail reader.  Such is life, but
please don't blame the OP for someone else's lack of reading
comprehension.

-Adam

2009\06\05@092348 by olin piclist

face picon face
M. Adam Davis wrote:
> I know of at least one regular poster here that chooses
> to reply to posts before reading the entire thread

Even if one did want to read forwards before replying to a particular post,
at some point that post is the last to hit the list and there is nothing to
read forward to.  Also keep in mind that the server delivers messages out of
order, apparently up to 10s of minutes sometimes.

In any case, that's how email lists work.  It is unreasonable to expect
people to jump around to look at future messages when replying to a
particular one.

Others may disagree, but I think the cutoff for taking the future into
account is about 1 day.  In other words, it's acceptable to process and
reply to messages in order if you've been gone less than a day.  People
should understand that's how email lists work and not get upset with
redundant replies within that window.  I actually think it's useful because
you get various people's views on a matter before they get biased by what
others have said.

When you are gone for more than a day, I do think it is your repsonsibility
to look ahead before replying.  When I'm gone for a long period of time, I
shut off the mail feed so it's not a issue.  When I'm just gone for a
weekend and am reading mail from the list Monday morning, for example, I
find it useful to not delete the messages that I would otherwise have
replied to.  Then after reading the accumulated mail it's easy to go back to
the few messages that weren't deleted and decide whether to reply to them
given the context of future discussion.

> please don't blame the OP for someone else's lack of reading
> comprehension.

Look at the messages in order, and you will see that important information
was missing or confusing at best.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

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