Searching \ for '[PIC] 18F6720 resetting itself' 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: '18F6720 resetting itself'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] 18F6720 resetting itself'
2006\08\17@105639 by Harold Hallikainen

face picon face
After producing several thousand systems, we're now finding that an
18F6720 based system is resetting itself on occasion for no apparent
reason. I've added the C18 code below to try to determine the reason for
the resets:

 WriteLogRecord(1,(RCON & 0x1f) | (STKPTR & 0xc0));        // log the power up
including the lsbs of the RCON register
                                                                                         // and the msbs of the stack pointer to log reason for reset
 #if 1                                                                        // include reason for reset
      PutRomString("\r\nSystem reset by \0");
      if((RCON & 0x01)==0) PutRomString("brownout, \0");
      if((RCON & 0x02)==0) PutRomString("power up, \0");
      if((RCON & 0x04)==0) PutRomString("sleep, \0");
      if((RCON & 0x08)==0) PutRomString("watchdog timeout, \0");
      if((RCON & 0x10)==0) PutRomString("reset instruction, \0");
      if((STKPTR & 0x40)==0x40) PutRomString("stack underflow, \0");
      if((STKPTR & 0x80)==0x80) PutRomString("stack overflow, \0");
 #endif
 RCON|=0x1f;                                // set all the reset detect registers


I'm getting "System reset by" messages with nothing following, which seems
to indicate that none of the bits in the RCON register were cleared by the
reset, nor were the stack overflow or underflow bits set. This seems to
indicate it was a reset caused by the MCLR input. However, I have a scope
on the MCLR pin set to single sweep should the voltage go below 3.96V.
MCLR is supposed to have a low threshhold of 0.2Vcc and Vcc is 5V, so MCLR
should drop to 1V before it triggers a reset.

So, watching the RCON register indicates I'm getting an MCLR reset, but
watching the MCLR pin does not show a reset there.

This problem comes and goes. The system ran for several hours yesterday,
but reset several times overnight.

Ideas?

THANKS!

Harold

--
FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available!

2006\08\17@110807 by William Couture

face picon face
On 8/17/06, Harold Hallikainen <spam_OUTharoldTakeThisOuTspamhallikainen.com> wrote:

> This problem comes and goes. The system ran for several hours yesterday,
> but reset several times overnight.
>
> Ideas?

If you run more than one system, do they reset at the same time?

Bill

--
Psst...  Hey, you... Buddy...  Want a kitten?  straycatblues.petfinder.org

2006\08\17@111731 by peter green

flavicon
face
iirc mclr is very very fast responding, possiblly too fast for your scope.

what exactly is connected to the mclr pin?

> {Original Message removed}

2006\08\17@111735 by Mark Rages

face picon face
On 8/17/06, Harold Hallikainen <.....haroldKILLspamspam@spam@hallikainen.com> wrote:
{Quote hidden}

How are you reading the message back?  It looks like you'll have extra
null characters.  For example, in the event of a brownout:
\r\nSystem reset by \0brownout, \0

So software that is expecting the C convention of null-terminated
strings won't read the second part.

Regards,
Mark
markrages@gmail
--
You think that it is a secret, but it never has been one.
 - fortune cookie

2006\08\17@111950 by Michael Rigby-Jones

picon face
>-----Original Message-----
>From: piclist-bouncesspamKILLspammit.edu [.....piclist-bouncesKILLspamspam.....mit.edu]
>Sent: 17 August 2006 15:35
>To: EraseMEpiclistspam_OUTspamTakeThisOuTmit.edu
>Subject: [PIC] 18F6720 resetting itself
>
>
>So, watching the RCON register indicates I'm getting an MCLR
>reset, but watching the MCLR pin does not show a reset there.
>
>This problem comes and goes. The system ran for several hours
>yesterday, but reset several times overnight.
>
>Ideas?

Could it be an uninitialised pointer, or string with no null termiator etc. that is causing the program counter to reach 0x0000 (either directly or by executing unprogrammed locations at the top end of memory and then rolling over)?

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.
=======================================================================

2006\08\17@112648 by Alan B. Pearce

face picon face
> This problem comes and goes. The system ran for several hours yesterday,
> but reset several times overnight.

Not a silicon error that MC hasn't let on about ? Does the new batch use
different date code/revision chips?

2006\08\17@112726 by Dominic Stratten

picon face
Harold - I had a similar problem myself not so long ago.

Things I came up to check were :

Adequate decoupling - especially if running at higher speeds. People
recommended a 10uF Tantalum, 1uF tantalum and 100nf multilayer as close to
the processor as possible

No floating ports

BOR bits properly set

In the end I traced mine down to a bit of code which when running as
designed was slightly too short on the interrupt to clear my WDT .  I fixed
the code but the problem still happened.

I then found the problem was down to the fact that if an interrupt occurred
during a 2 cycle operation my STATUS register was not stored as it was
cleared when the interrupt jump happened - a quick modification with the
RETFIE FAST cured the issue - took me 2 weeks of debugging in my spare time
to find that one out though lol.

Dom

{Original Message removed}

2006\08\17@121319 by Harold Hallikainen

face picon face

>> I'm getting "System reset by" messages with nothing following, which
>> seems
>> to indicate that none of the bits in the RCON register were cleared by
>> the
>> reset, nor were the stack overflow or underflow bits set.
>
> How are you reading the message back?  It looks like you'll have extra
> null characters.  For example, in the event of a brownout:
> \r\nSystem reset by \0brownout, \0
>
> So software that is expecting the C convention of null-terminated
> strings won't read the second part.
>
>

THANKS for the several responses so far! I'll comment on them all here.

First off, I wrote the PrintRomString() (or whatever I called it) before
MCC18 had a printf(). It just sends strings from flash to the uart
terminating on a null. I just cycled power to the unit and this is what I
get:

00>
System reset by brownout, power up,

00>

So, it seems that my output of RCON is working.

The code makes very rare use of pointers, generally just for pointing into
strings. I tend to use arrays and indices instead of pointers. Code checks
for the index being within bounds of the array.

I've been watching the MCLR line with a Tek TDS3012 and have not seen
anything on MCLR. I have the scope set up to trigger on a negative edge at
3.96V. It's set for DC triggering (no high frequency reject). The MCLR
line has a 10K to +5V and a series 470 ohm and 0.68uF to ground. This was
copied from a Microchip eval board to allow the ICD2 to drive MCLR. MCLR,
PGD, and PGC go to a programming header.

If I have a problem in an interrupt, I'd expect a stack undeflow or
overflow, which I'm not seeing according to the STKPTR register. Further,
the code is pretty much unchanged in over a year. The problem is affecting
very few units.

Someone asked if all the units with problems start resetting at the same
time. It's difficult to tell, but I think not. I'm told that units that
had this problem a week ago have now not reset in a week.

Based on what I'm seeing so far, I think I'll try putting a wire wrap
jumper between the +5V and MCLR pins on the programming header and see if
the problem goes away.

THANKS!

Harold


--
FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available!

2006\08\17@131617 by Mark Rages

face picon face
On 8/17/06, Harold Hallikainen <haroldspamspam_OUThallikainen.com> wrote:
{Quote hidden}

OK, I guess it looked odd to me because C compilers give you a '\0' at
the end of string constants anyway.  But I an extra one won't hurt,
except for code space.

Regards,
Mark
markrages@gmail
--
You think that it is a secret, but it never has been one.
 - fortune cookie

2006\08\18@105012 by Harold Hallikainen

face picon face
Following up on yesterday... I not that the datasheet indicates an MCLR
pulse has to be at least 2us and go below 0.2Vcc. It also says MCLR is
filtered to avoid false resets. I tried tying MCLR directly to Vcc on the
programming header on our board. It worked fine through yesterday, but
reset about 25 times overnight. The RCON and STKPTR registers are not
reporting a reset cause which, I believe, points back to MCLR, since it
leaves these registers unchanged. The night before last, I left a DC
triggered scope (Tek TDS3012) set to single sweep on a negative edge going
below about 4.6V on MCLR. It never triggered. So, any more ideas? About
the only thing I can think of is a GOTO sending the program back to the
beginning. This is written in C and I don't have any GOTOs. I do have a
few assembly code sections with state machines, so I'll have to check
those to make sure they have good bounds checking. Since only addresses
can be put on the stack, and stack overflow and underflow are reported in
the STKPTR register, it doesn't seem like it's a stack corruption problem.
This has only occurred on a few units out of thousands made, so I'm
thinking it's a hardware problem... but what hardware?

Thanks for any ideas!

Harold

--
FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available!

2006\08\18@110925 by William Couture

face picon face
On 8/18/06, Harold Hallikainen <@spam@haroldKILLspamspamhallikainen.com> wrote:

>  It worked fine through yesterday, but reset about 25 times overnight.

You also mentioned in your first post that it reset when running overnight,
but apparently not during the day.

The question is:  what is different at night?  That's why I asked if multiple
units reset at the same time (could indicate a power problem in the
building).

Are the lights off at night? (Flourescent lights create AC noise)
Are you sending it input during the day, but is it just running idle at
night?

Bill

--
Psst...  Hey, you... Buddy...  Want a kitten?  straycatblues.petfinder.org

2006\08\18@112439 by Tamas Rudnai

face picon face
Harold, is there any chance that the problem is around the code? So that if
escapes somehow and runs behind your code until reaches the end of the
program memory and overflows to the reset vector?

Tamas


On 18/08/06, William Couture <KILLspambcoutureKILLspamspamgmail.com> wrote:
{Quote hidden}

> -

2006\08\18@112532 by John Scott

flavicon
face
Also - is there a big ambient temperature difference at night. Maybe
that chip is faulty.

Regards

William Couture wrote:
{Quote hidden}

2006\08\18@123009 by Marcel duchamp

picon face
Harold Hallikainen wrote:
> Following up on yesterday... I not that the datasheet indicates an MCLR
> pulse has to be at least 2us and go below 0.2Vcc. It also says MCLR is
> filtered to avoid false resets. I tried tying MCLR directly to Vcc on the
> programming header on our board. It worked fine through yesterday, but
> reset about 25 times overnight.

> so I'm
> thinking it's a hardware problem... but what hardware?
>
> Thanks for any ideas!
>
> Harold
>

What's your power supply setup for the units that reset overnight? If
it's derived from AC mains power, try running it on battery.

Do you have hardware I/O connected to it? Noise could come in on those
lines.

Is it tucked away in the shop next to the EMI generator that only comes
on at night?

Is it up against the wall shared by the business next door who has their
high power aircompressor come on at night?

Any other environmental issues you might know of that could be related
to this?

2006\08\18@170852 by Brent Brown

picon face
Harold Hallikainen wrote:
> Following up on yesterday... I not that the datasheet indicates an MCLR
> pulse has to be at least 2us and go below 0.2Vcc. It also says MCLR is
> filtered to avoid false resets. I tried tying MCLR directly to Vcc on
> the programming header on our board. It worked fine through yesterday,
> but reset about 25 times overnight.

Sounds like you are doing the right things but it's time to double/tripple check:

- Don't trust your scope to say there is no glitch present. Loading of the scope probe
itself could affect it, a glitch may be present on Vdd or other pin and not MCLR, the
scope may not behave the way you expect it.

- Go back to a 10k pullup on MCLR and add a 100nF cap (MCLR to GND), see if
that proves anything.

- RCON should really be able to tell you what's happening, but the meaning is tricky
to decode. It's possible that you are getting some kind of valid reset but you're not
decoding it correctly (I know you posted your code for this before). You have to trust
that Microchip's hardware does what it says it does until you can prove otherwise.

- If code execution goes wayward and PC wraps around to 0000 (jump directly to
0000 seems lower probability) you could probably put some code at end of memory
to catch it.

--
Brent Brown, Electronic Design Solutions
16 English Street, St Andrews,
Hamilton 3200, New Zealand
Ph: +64 7 849 0069
Fax: +64 7 849 0071
Cell: 027 433 4069
eMail:  TakeThisOuTbrent.brownEraseMEspamspam_OUTclear.net.nz


2006\08\20@134422 by Harold Hallikainen

face picon face
Well, following up on this, I left the system running for the weekend with
the WDT, brown out, stack over/underflow, etc. turned off. I'll see on
Monday if the system has crashed. I'll try adding some code at the end of
flash to see if I'm getting a runaway program causing a PC rollover. It's
interesting that this just started happenning on a very few systems out of
the thousands that have been built in the past few years.

One thing I'm wondering about is chip programming. We're doing ICSP using
the ICD-2. I know that the ProMate3 is a "production programmer" while the
ICD is not, though the ICD has served me well for several years. I recall
previously reading that the ProMate does program verify at a variety of
Vdd voltages, while the ICD does not. How can the ProMate do this when the
chip is in circuit and the system power supply is powering the PIC? Or
does the ProMate power the PIC (and the rest of the system)? Does anyone
think we're possibly getting flaky flash programming? How does ICD
programming compare with self-programming through a bootloader? We do a
lot of field updates through a bootloader. Is its programming of flash
reliable?

THANKS!

Harold

--
FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available!

2006\08\20@140327 by olin piclist

face picon face
Harold Hallikainen wrote:
> I recall previously reading that the ProMate does
> program verify at a variety of Vdd voltages, while the ICD does not.
> How can the ProMate do this when the chip is in circuit and the
> system power supply is powering the PIC?

It probably can't.  Most likely you have to let the programmer power the
circuit.

If you're thinking about getting a real production programmer, check out my
ProProg (http://www.embedinc.com/proprog).  It's 1/3 the price of the PM3
and a lot less klunky.  It also expects to control the target Vdd during
programming.


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2006\08\20@144628 by peter green

flavicon
face

>  How does ICD
> programming compare with self-programming through a bootloader?
a bootloader will obviously not verify at multiple voltages, so i imagine
its programming will be no more or less reliable than a development
programmer like the ICD2.

I think multi voltage verification is more about detecting dodgy chips at
production time before they cause issues in use than it is about verifying
successfull programming.

2006\08\20@145213 by Harold Hallikainen

face picon face

> Harold Hallikainen wrote:
>> I recall previously reading that the ProMate does
>> program verify at a variety of Vdd voltages, while the ICD does not.
>> How can the ProMate do this when the chip is in circuit and the
>> system power supply is powering the PIC?
>
> It probably can't.  Most likely you have to let the programmer power the
> circuit.
>
> If you're thinking about getting a real production programmer, check out
> my
> ProProg (http://www.embedinc.com/proprog).  It's 1/3 the price of the PM3
> and a lot less klunky.  It also expects to control the target Vdd during
> programming.
>

Thanks! I'll keep that in mind!

Harold

--
FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available!

2006\08\21@194809 by Harold Hallikainen

face picon face
This is my week for pic problems! Back on this 18f6720 resetting itself, I
thought I remembered something about setting a breakpoint on the ICD-2 on
wdt timeout, stack overflow, etc. The help files mention setting it on
stack overflow, but I don't see it in either of the breakpoint menus. Can
I set a breakpoint on these?

Thanks!

Harold

--
FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available!

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