On Aug 1, 10:46 pm, Viktor <vkes...@gmail.com> wrote:
> On Aug 1, 4:23 am, Steven Woody <narkewo...@gmail.com> wrote:
>
> > On Aug 1, 12:44 am, Viktor <vkes...@gmail.com> wrote:
> > > This type of thing usually happens to me when I'm not wiggling the
> > > watchdog pin frequently enough.
> > > What I do is that the watchdog wiggling function also writes a byte
> > > value into a safe location. Whenever the system resets, this value is
> > > shown during the self-test procedure.
> > > This way I can tell where the program was before the reset occurred.
>
> > > Maybe it's a stack overflow?
>
> > would you please show a simple sample about setting such a value you
> > mentioned? thank you.
>
> First, find a location which will not be overwritten by a reset. Then,
> in a function for wiggling the watchdog
>
> void WWDOG(unsigned char value)
>
> write the value passed to the function into this location.
> Sprinkle a fair amount of these function calls around your program,
> each using a different value. An important function or subroutine may
> have e.g. all the 0x4n values, where n=0 to F and so on.
>
> When you reset the processor, the self-test code should display the
> value last stored by the WWDOG function.
> If the reset occurs far too seldom for you to see it like this, store
> the value in an EEPROM or something and read it out after the reset
> has happened.
>
> All this has nothing to do with wiggling the watchdog. It just seems
> convenient to put it in the same function.

thanks. it so much similar with what i am doing now.

On Aug 1, 4:23 am, Steven Woody <narkewo...@gmail.com> wrote:
> On Aug 1, 12:44 am, Viktor <vkes...@gmail.com> wrote:


> > This type of thing usually happens to me when I'm not wiggling the
> > watchdog pin frequently enough.
> > What I do is that the watchdog wiggling function also writes a byte
> > value into a safe location. Whenever the system resets, this value is
> > shown during the self-test procedure.
> > This way I can tell where the program was before the reset occurred.
>
> > Maybe it's a stack overflow?
>
> would you please show a simple sample about setting such a value you
> mentioned? thank you.

First, find a location which will not be overwritten by a reset. Then,
in a function for wiggling the watchdog

void WWDOG(unsigned char value)

write the value passed to the function into this location.
Sprinkle a fair amount of these function calls around your program,
each using a different value. An important function or subroutine may
have e.g. all the 0x4n values, where n=0 to F and so on.

When you reset the processor, the self-test code should display the
value last stored by the WWDOG function.
If the reset occurs far too seldom for you to see it like this, store
the value in an EEPROM or something and read it out after the reset
has happened.

All this has nothing to do with wiggling the watchdog. It just seems
convenient to put it in the same function.

On Aug 1, 9:57 am, Bob <bob36...@yahoo.com> wrote:
> On Jul 31, 8:18 am, Steven Woody <narkewo...@gmail.com> wrote:
>
> > hi,
>
> > may be caused by a buggy code somewhre, a system we developed under
> > M16C microprocessor will reset itself in some cases.  i want to find
> > out what's the cause of the reset ( the hardware watchdog was turned
> > off ).  is there any idea about this kind of problem? and, could you
> > please introduce any method used to detect causes of system reset?
>
> The standard way to solve this kind of problem is to use
> "breadcrumbs":  leave behind small nuggets of information
> that you can later use to track down the problem.  If you
> have some RAM that isn't cleared by a reset, that is the
> best.  Otherwise, you can output a bit pattern on some unused
> I/O pins, and capture the patterns with a logic analyser.  You
> can buy a decent logic analyser for a few hundred dollars.
> I have a Bitscope BS50.  It paid for itself the first time I used it.
>
> Using the breadcrumb method, you should be able to rapidly
> zero in on where your code is going haywire.  If there is no
> single location, then you have a harder problem.  If this is the
> case, check the following:
>
> 1.  Is the watchdog really off?  Are you sure?
> 2.  Is an interrupt goofing up the stack?
> 3.  Are you disabling interrupts around critical code?
> 4.  Is your stack growing too big?  Put a sentinel byte
>      at the bottom of your stack, and check periodically
>      to make sure it is never overwritten.
> 5.  Maybe you have more than one bug.
>
> Unless this is a homebrew board, it is unlikely to be a
> hardware problem.  It is even less likely to be a compiler
> problem.

many thanks for your guide!  could you please introduce to me how to
do the 2 and 4?

On Aug 1, 12:44 am, Viktor <vkes...@gmail.com> wrote:
> On Jul 31, 5:18 pm, Steven Woody <narkewo...@gmail.com> wrote:
>
> > hi,
>
> > may be caused by a buggy code somewhre, a system we developed under
> > M16C microprocessor will reset itself in some cases.  i want to find
> > out what's the cause of the reset ( the hardware watchdog was turned
> > off ).  is there any idea about this kind of problem? and, could you
> > please introduce any method used to detect causes of system reset?
>
> > thanks in advance.
>
> > -
> > narke
>
> This type of thing usually happens to me when I'm not wiggling the
> watchdog pin frequently enough.
> What I do is that the watchdog wiggling function also writes a byte
> value into a safe location. Whenever the system resets, this value is
> shown during the self-test procedure.
> This way I can tell where the program was before the reset occurred.
>
> Maybe it's a stack overflow?

would you please show a simple sample about setting such a value you
mentioned? thank you.

On Jul 31, 8:18 am, Steven Woody <narkewo...@gmail.com> wrote:
> hi,
>
> may be caused by a buggy code somewhre, a system we developed under
> M16C microprocessor will reset itself in some cases.  i want to find
> out what's the cause of the reset ( the hardware watchdog was turned
> off ).  is there any idea about this kind of problem? and, could you
> please introduce any method used to detect causes of system reset?

The standard way to solve this kind of problem is to use
"breadcrumbs":  leave behind small nuggets of information
that you can later use to track down the problem.  If you
have some RAM that isn't cleared by a reset, that is the
best.  Otherwise, you can output a bit pattern on some unused
I/O pins, and capture the patterns with a logic analyser.  You
can buy a decent logic analyser for a few hundred dollars.
I have a Bitscope BS50.  It paid for itself the first time I used it.

Using the breadcrumb method, you should be able to rapidly
zero in on where your code is going haywire.  If there is no
single location, then you have a harder problem.  If this is the
case, check the following:

1.  Is the watchdog really off?  Are you sure?
2.  Is an interrupt goofing up the stack?
3.  Are you disabling interrupts around critical code?
4.  Is your stack growing too big?  Put a sentinel byte
     at the bottom of your stack, and check periodically
     to make sure it is never overwritten.
5.  Maybe you have more than one bug.

Unless this is a homebrew board, it is unlikely to be a
hardware problem.  It is even less likely to be a compiler
problem.

"Steven Woody" <narkewoody@gmail.com> wrote in message 
news:1185897467.174976.3850@e9g2000prf.googlegroups.com...
> On Jul 31, 11:42 pm, "Peter Dickerson"
> <firstname.lastn...@REMOVE.tesco.net> wrote:
>> "Steven Woody" <narkewo...@gmail.com> wrote in message
>>
>> news:1185895126.175695.50750@e16g2000pri.googlegroups.com...
>>
>> > hi,
>>
>> > may be caused by a buggy code somewhre, a system we developed under
>> > M16C microprocessor will reset itself in some cases.  i want to 
>> > find
>> > out what's the cause of the reset ( the hardware watchdog was 
>> > turned
>> > off ).  is there any idea about this kind of problem? and, could 
>> > you
>> > please introduce any method used to detect causes of system reset?
>>
>> I've used the M16C62 without problem. It's many years now sincebut 
>> there are
>> thousands in the field without every reporting this. Are you using 
>> internal
>> or external memory? Clock speed? I used Mitsubishi's own NC30 
>> compiler in
>> large model.
>>
>> Peter
>
> mine is also M16C62 and it equips 31k internal memory.  i think that
> is a code bug and i just want to find out what's the cause of reset.
> if that is a fault of IAR compiler, what kind of defects will cause a
> reset?  thank you.

Are you seeing a hardware or software reset? If hardware, is it possible 
that some illegal state (e.g. bus contention) is drawing so much current 
from the PSU that your reset supervisor kicks in?

If software, do you have traps in your code - i.e. excluded states which 
when detected result in a software reset? Is there anything in your code 
which results in a software reset? If so, maybe write a "reason" code to 
a location which doesn't get cleared at (software) reset and report it 
somehow after startup.

Does the processor itself have traps that can result in a reset? (Many 
do - not sure about yours.)

Just some thoughts...

Steve
http://www.fivetrees.com 

On Jul 31, 5:18 pm, Steven Woody <narkewo...@gmail.com> wrote:
> hi,
>
> may be caused by a buggy code somewhre, a system we developed under
> M16C microprocessor will reset itself in some cases.  i want to find
> out what's the cause of the reset ( the hardware watchdog was turned
> off ).  is there any idea about this kind of problem? and, could you
> please introduce any method used to detect causes of system reset?
>
> thanks in advance.
>
> -
> narke

This type of thing usually happens to me when I'm not wiggling the
watchdog pin frequently enough.
What I do is that the watchdog wiggling function also writes a byte
value into a safe location. Whenever the system resets, this value is
shown during the self-test procedure.
This way I can tell where the program was before the reset occurred.

Maybe it's a stack overflow?

On Jul 31, 11:42 pm, "Peter Dickerson"
<firstname.lastn...@REMOVE.tesco.net> wrote:
> "Steven Woody" <narkewo...@gmail.com> wrote in message
>
> news:1185895126.175695.50750@e16g2000pri.googlegroups.com...
>
> > hi,
>
> > may be caused by a buggy code somewhre, a system we developed under
> > M16C microprocessor will reset itself in some cases.  i want to find
> > out what's the cause of the reset ( the hardware watchdog was turned
> > off ).  is there any idea about this kind of problem? and, could you
> > please introduce any method used to detect causes of system reset?
>
> I've used the M16C62 without problem. It's many years now sincebut there are
> thousands in the field without every reporting this. Are you using internal
> or external memory? Clock speed? I used Mitsubishi's own NC30 compiler in
> large model.
>
> Peter

mine is also M16C62 and it equips 31k internal memory.  i think that
is a code bug and i just want to find out what's the cause of reset.
if that is a fault of IAR compiler, what kind of defects will cause a
reset?  thank you.

John Devereux wrote:

> Steven Woody <narkewoody@gmail.com> writes:
> 

>>
>>ps. we're suing IAR C Compiler
> 
> 
> About time... can I join your class-action suit?
>  
>   :)

With all recent changes, IAR definitely needs a beating.

:-(


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

"John Devereux" <jdREMOVE@THISdevereux.me.uk> wrote in message 
news:876440oa6s.fsf@cordelia.devereux.me.uk...
> Steven Woody <narkewoody@gmail.com> writes:
>
>> On Jul 31, 11:18 pm, Steven Woody <narkewo...@gmail.com> wrote:
>>> hi,
>>>
>>> may be caused by a buggy code somewhre, a system we developed under
>>> M16C microprocessor will reset itself in some cases.  i want to find
>>> out what's the cause of the reset ( the hardware watchdog was turned
>>> off ).  is there any idea about this kind of problem? and, could you
>>> please introduce any method used to detect causes of system reset?
>>>
>>> thanks in advance.
>>>
>>> -
>>> narke
>>
>> ps. we're suing IAR C Compiler
>
> About time... can I join your class-action suit?

Me too! My experience with M16C and IAR was dire. To be fair it was quite 
some years ago (2000?), but what I evaluted was not fit to be called a 
compiler - IAR did themselves no favours by letting potential customers see 
it. My experience with other processors previously (H8) was usable, just.

Peter