Searching \ for '[PIC] How to determine cause of reset' 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: 'How to determine cause of reset'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] How to determine cause of reset'
2008\08\13@083936 by Stephen D. Barnes

flavicon
face
I'm using the dsPIC30F2010. Rolled my own RC servo routine for one
servo. Every once in a while (approx 23 sec) the servo will twitch.
Using ICD2 in debug mode, found the PIC is going to the reset vector. I
have, I hope, examined the code in detail and found no reason that I can
see for the behavior. Is there a non-volatile register that retains the
micro's status/reason for reset? I have RTFM but do not seem to find, or
have overlooked the answer to this. Any pointers are appreciated!

--
Regards,
Stephen D. Barnes

2008\08\13@090304 by Picbits Sales

flavicon
face
Might sound glaringly obvious but could it possible be a watchdog timer
reset ?

Other things I've noticed that cause suprious resets are lack of decoupling
capacitors (I had big problems with this once).

It could also be that you are experiencing a stack overflow reset - make
sure any calls/returns etc are matched and you're not jumping outside any
loops.

Dom
{Original Message removed}

2008\08\13@090409 by Alan B. Pearce

face picon face
>I have RTFM but do not seem to find, or have overlooked
>the answer to this. Any pointers are appreciated!

23 seconds sounds like watchdog timeout.

The other one I would look for is brownout detect turned on, and a power
supply glitch causing a brownout reset.

2008\08\13@094005 by olin piclist

face picon face
Stephen D. Barnes wrote:
> I'm using the dsPIC30F2010. Rolled my own RC servo routine for one
> servo. Every once in a while (approx 23 sec) the servo will twitch.
> Using ICD2 in debug mode, found the PIC is going to the reset vector.

Sounds like a unhandled trap caused by a bug.

> I have, I hope, examined the code in detail and found no reason that
> I can see for the behavior.

The best thing is to use the ICE to set a breakpoint at the reset vector and
examine the trace log to see how you got there.  If you're stuck with the
ICD2, you can still set a breakpoint at the reset vector, then examine the
stack and RCON, although it's a lot more flaky than the ICE.  I hear the
RealICE is much better than the ICD2 but I haven't tried it yet.

I suspect you are getting a trap.  I usually install handlers for all traps
that just spin in a NOP loop.  That allows setting breakpoints there.  The
stack data tells you exactly where the offending instruction is.

> Is there a non-volatile register that
> retains the micro's status/reason for reset?

RCON gives some information about this.  It's volatile, but then I don't
understand why you want it to be non-volatile.  That doesn't make any sense.

> I have RTFM but do not
> seem to find, or have overlooked the answer to this. Any pointers are
> appreciated!

DsPIC 30F Family Reference Manual, Section 8 "Reset".


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

2008\08\13@165022 by Stephen D. Barnes

flavicon
face
Olin Lathrop wrote:

<snip>
> RCON gives some information about this.  It's volatile, but then I don't
> understand why you want it to be non-volatile.  That doesn't make any sense.
>
>  
>> I have RTFM but do not
>> seem to find, or have overlooked the answer to this. Any pointers are
>> appreciated!
>>    
>
> DsPIC 30F Family Reference Manual, Section 8 "Reset".
>
>
> ********************************************************************
> Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
> (978) 742-9014.  Gold level PIC consultants since 2000.
>  
The non-volatile thing was just grabbing at straws late at night! Your
reply is full of good advice that I had not thought of.
I do not have an ICE but the trap handling and breakpoint at reset are
good ideas that I can use.
Thanks Olin.

--
Regards,
Stephen D. Barnes

2008\08\13@165501 by Stephen D. Barnes

flavicon
face
Alan B. Pearce wrote:
>> I have RTFM but do not seem to find, or have overlooked
>> the answer to this. Any pointers are appreciated!
>>    
>
> 23 seconds sounds like watchdog timeout.
>
> The other one I would look for is brownout detect turned on, and a power
> supply glitch causing a brownout reset.
>
>  
Watchdog is definitely disabled. Brownout is enabled. Target runs at 5v
and brownout is set at 2.7v. Target Vdd is 4.98 - 5.00 Vdc when viewed
with 100MHz scope. Olin suggested implementing a trap handler. Will give
it a try this evening.
Thanks for the reply.

--
Regards,
Stephen D. Barnes

2008\08\13@165832 by Stephen D. Barnes

flavicon
face
Picbits Sales wrote:
> Might sound glaringly obvious but could it possible be a watchdog timer
> reset ?
>
> Other things I've noticed that cause suprious resets are lack of decoupling
> capacitors (I had big problems with this once).
>
> It could also be that you are experiencing a stack overflow reset - make
> sure any calls/returns etc are matched and you're not jumping outside any
> loops.
>
> Dom
> {Original Message removed}

2008\08\13@165859 by Apptech

face
flavicon
face
> 23 seconds sounds like watchdog timeout.

24 MHz clock?

1/24 MHz x 65536 x 256 x 32 =~  22.37 seconds
FWIW


       R

2008\08\13@174707 by Picbits Sales

flavicon
face
Let us know how you get on - its always nice to see an actual solution to
the problem :-)

Good luck

Dom
{Original Message removed}

2008\08\13@180525 by Stephen D. Barnes

flavicon
face
Apptech wrote:
>> 23 seconds sounds like watchdog timeout.
>>    
>
> 24 MHz clock?
>
> 1/24 MHz x 65536 x 256 x 32 =~  22.37 seconds
> FWIW
>
>
>         R
>
>  
10MHz resonator...no PLL. Watchdog definitely off.

--
Regards,
Stephen D. Barnes

2008\08\13@180555 by Stephen D. Barnes

flavicon
face
Picbits Sales wrote:
> Let us know how you get on - its always nice to see an actual solution to
> the problem :-)
>
> Good luck
>
> Dom
> {Original Message removed}

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