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
How to find why the system reset?
Started by ●July 31, 2007
Reply by ●July 31, 20072007-07-31
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. > > - > narkeps. we're suing IAR C Compiler
Reply by ●July 31, 20072007-07-31
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 CompilerAbout time... can I join your class-action suit? :) -- John Devereux
Reply by ●July 31, 20072007-07-31
"Steven Woody" <narkewoody@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
Reply by ●July 31, 20072007-07-31
"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
Reply by ●July 31, 20072007-07-31
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
Reply by ●July 31, 20072007-07-31
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. > > Petermine 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.
Reply by ●July 31, 20072007-07-31
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. > > - > narkeThis 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?
Reply by ●July 31, 20072007-07-31
"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
Reply by ●July 31, 20072007-07-31
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.
