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.
How to find why the system reset?
Started by ●July 31, 2007
Reply by ●July 31, 20072007-07-31
Reply by ●August 1, 20072007-08-01
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?
Reply by ●August 1, 20072007-08-01
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.
Reply by ●August 1, 20072007-08-01
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.