How to determine cause of reset

[Stephen D. Barnes-2]

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

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Picbits Sales]

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 -----
From: "Stephen D. Barnes" <stephendbarnes@...>
To: "MIT PICList" <PICLIST@...>
Sent: Wednesday, August 13, 2008 1:37 PM
Subject: [PIC] How to determine cause of reset

> 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
>
> --
> http://www.piclist.com PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>
>
> No virus found in this incoming message.
> Checked by AVG - http://www.avg.com
> Version: 8.0.138 / Virus Database: 270.6.1/1608 - Release Date: 12/08/2008
> 16:59
>
>
>

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Alan B. Pearce]

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

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Olin Lathrop]

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
[phone].  Gold level PIC consultants since 2000.
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Apptech]

> 23 seconds sounds like watchdog timeout.

24 MHz clock?

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


        R

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Stephen D. Barnes-2]

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
> [phone].  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

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Stephen D. Barnes-2]

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

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Stephen D. Barnes-2]

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 -----
> From: "Stephen D. Barnes" <stephendbarnes@...>
> To: "MIT PICList" <PICLIST@...>
> Sent: Wednesday, August 13, 2008 1:37 PM
> Subject: [PIC] How to determine cause of reset
>
>
>  
>> 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
>>
>> --
>> http://www.piclist.com PIC/SX FAQ & list archive
>> View/change your membership options at
>> http://mailman.mit.edu/mailman/listinfo/piclist
>>
>>
>> No virus found in this incoming message.
>> Checked by AVG - http://www.avg.com
>> Version: 8.0.138 / Virus Database: 270.6.1/1608 - Release Date: 12/08/2008
>> 16:59
>>
>>
>>
>>    
>
>  

Thanks for the reply. Target is properly de-coupled, call/return
structures appear ok. Olin posted some good ideas that I will try this
evening. Thanks.

--
Regards,
Stephen D. Barnes

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Alan Smith-10]

I've been looking in all the usual places (AKM, TI, ADI, Cirrus) for a 24bit CODEC that has built into it a digital 5 band eq circuit.  Anyone ever run across one?  Google doesn't come back with any hardware solutions, just software.


     
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Picbits Sales]

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

Good luck

Dom
----- Original Message -----
From: "Stephen D. Barnes" <stephendbarnes@...>
To: "Microcontroller discussion list - Public." <piclist@...>
Sent: Wednesday, August 13, 2008 9:56 PM
Subject: Re: [PIC] How to determine cause of reset

> 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 -----
>> From: "Stephen D. Barnes" <stephendbarnes@...>
>> To: "MIT PICList" <PICLIST@...>
>> Sent: Wednesday, August 13, 2008 1:37 PM
>> Subject: [PIC] How to determine cause of reset
>>
>>
>>
>>> 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
>>>
>>> --
>>> http://www.piclist.com PIC/SX FAQ & list archive
>>> View/change your membership options at
>>> http://mailman.mit.edu/mailman/listinfo/piclist
>>>
>>>
>>> No virus found in this incoming message.
>>> Checked by AVG - http://www.avg.com
>>> Version: 8.0.138 / Virus Database: 270.6.1/1608 - Release Date:
>>> 12/08/2008
>>> 16:59
>>>
>>>
>>>
>>>
>>
>>
> Thanks for the reply. Target is properly de-coupled, call/return
> structures appear ok. Olin posted some good ideas that I will try this
> evening. Thanks.
>
> --
> Regards,
> Stephen D. Barnes
>
> --
> http://www.piclist.com PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>
>
> No virus found in this incoming message.
> Checked by AVG - http://www.avg.com
> Version: 8.0.138 / Virus Database: 270.6.3/1610 - Release Date: 13/08/2008
> 16:14
>
>
>

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Stephen D. Barnes-2]

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

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Stephen D. Barnes-2]

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 -----
> From: "Stephen D. Barnes" <stephendbarnes@...>
> To: "Microcontroller discussion list - Public." <piclist@...>
> Sent: Wednesday, August 13, 2008 9:56 PM
> Subject: Re: [PIC] How to determine cause of reset
>
>
>  
>> 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 -----
>>> From: "Stephen D. Barnes" <stephendbarnes@...>
>>> To: "MIT PICList" <PICLIST@...>
>>> Sent: Wednesday, August 13, 2008 1:37 PM
>>> Subject: [PIC] How to determine cause of reset
>>>
>>>
>>>
>>>      
>>>> 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
>>>>
>>>> --
>>>> http://www.piclist.com PIC/SX FAQ & list archive
>>>> View/change your membership options at
>>>> http://mailman.mit.edu/mailman/listinfo/piclist
>>>>
>>>>
>>>> No virus found in this incoming message.
>>>> Checked by AVG - http://www.avg.com
>>>> Version: 8.0.138 / Virus Database: 270.6.1/1608 - Release Date:
>>>> 12/08/2008
>>>> 16:59
>>>>
>>>>
>>>>
>>>>
>>>>        
>>>      
>> Thanks for the reply. Target is properly de-coupled, call/return
>> structures appear ok. Olin posted some good ideas that I will try this
>> evening. Thanks.
>>
>> --
>> Regards,
>> Stephen D. Barnes
>>
>> --
>> http://www.piclist.com PIC/SX FAQ & list archive
>> View/change your membership options at
>> http://mailman.mit.edu/mailman/listinfo/piclist
>>
>>
>> No virus found in this incoming message.
>> Checked by AVG - http://www.avg.com
>> Version: 8.0.138 / Virus Database: 270.6.3/1610 - Release Date: 13/08/2008
>> 16:14
>>
>>
>>
>>    
>
>  

Will do. Getting started in about an hour.

--
Regards,
Stephen D. Barnes

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Martin Klingensmith]

alan smith wrote:
> I've been looking in all the usual places (AKM, TI, ADI, Cirrus) for a 24bit CODEC that has built into it a digital 5 band eq circuit.  Anyone ever run across one?  Google doesn't come back with any hardware solutions, just software.
>
>
>      
>  
Well at that point you're kind of specifying a DSP. If you've already
checked Cirrus, that would have been your best bet IMO.
-
Martin
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist