How to find why the system reset?

ps. we're suing IAR C Compiler

About time... can I join your class-action suit? :)

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

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

With all recent changes, IAR definitely needs a beating.

:-(

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

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.

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?

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

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.

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

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

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.