Getting unwanted resets

Started by Dr Stewart Prince July 20, 2005
We just can't seem to get rid to the resets.....we have a d60a based
board we use in an automotive ignition controller and every so often, we
get a reset. Is this microcontroller just very sensitive to EMI?? Is
there a software way to determine if the resets are coming from the COP
or from an external RESET?

I've tried everything from a 4 layer board to massive amounts of power
supply filtering, but nothing seems to work. There is an IGBT on the
board that is used in the ignition circuit, but the system doesn't reset
all that often....maybe once every 1/2 hour or so. Of course, even once
is too much.

Any ideas?

Stewart Prince
Professor, Mech Eng
CSUN

>
>




Its always hard to give useful advice for this sort of problem. Most of
the things I can suggest will be things that you have already tried. I'll
try anyway. Maybe one suggestion will be something you haven't tried.

The IGBT circuit is certainly a prime suspect. Could you arrange a test
where the only major difference from normal operation is that there is no
power to the IGBT circuit?

An irregular MCU clock will cause some really mysterious effects. Can you
arrange to look at the ECLK signal to make sure it is stable and boringly
uniform?

Looking at the power supplies and ground for occasional fast transients is
also a good idea, but you probably have already gotten tired of doing that.

An ugly possibility is that the reset is somehow caused by a bug that shows
up only when an interrupt occurs at just the right time in a piece of
vulnerable code. This could have the symptom you describe.

I have found some of this kind of bug by careful code review.

I have also sometimes been able to figure out ways to make the bug occur
more often. Then the knowledge of what made the problem more frequent help
me converge on the actual source of the problem.

More notes below.

Steve Russell
Nohau Emulators

At 02:31 PM 7/20/2005, you wrote:
>We just can't seem to get rid to the resets.....we have a d60a based
>board we use in an automotive ignition controller and every so often, we
>get a reset. Is this microcontroller just very sensitive to EMI?? Is
>there a software way to determine if the resets are coming from the COP
>or from an external RESET?

The external reset and power on reset vectors are the same, but the COP
failure and clock monitor failure resets have different vectors, so you can
easily detect whether they happen.

While you are in the interrupt vectors, make sure that they are all set to
point to code.

I believe that pointing unexpected interrupts to an infinite loop is better
than doing an RTI. An RTI may not reset the interrupt flag that is causing
the interrupt, resulting in an interrupt loop. The infinite loop makes it
easy to determine that there was an unexpected interrupt if you have a
debugger connected.

Flashing a light or making a noise will get you the information if you
don't have a debugger connected.

>I've tried everything from a 4 layer board to massive amounts of power
>supply filtering, but nothing seems to work. There is an IGBT on the
>board that is used in the ignition circuit, but the system doesn't reset
>all that often....maybe once every 1/2 hour or so. Of course, even once
>is too much.
>
>Any ideas?
>
>Stewart Prince
>Professor, Mech Eng
>CSUN
>
> >
> >
>
>Yahoo! Groups Links >
>




There is different reset vector location for a COP reset. I write the reset
vector type to a variable that I can chekc later in my code to identify if
it was a COP reset.

-- Adrian

----- Original Message -----
From: "Steve Russell" <stever@stev...>
To: <68HC12@68HC...>
Sent: Thursday, July 21, 2005 8:26 AM
Subject: Re: [68HC12] Getting unwanted resets > Its always hard to give useful advice for this sort of problem. Most of
> the things I can suggest will be things that you have already tried. I'll
> try anyway. Maybe one suggestion will be something you haven't tried.
>
> The IGBT circuit is certainly a prime suspect. Could you arrange a test
> where the only major difference from normal operation is that there is no
> power to the IGBT circuit?
>
> An irregular MCU clock will cause some really mysterious effects. Can you
> arrange to look at the ECLK signal to make sure it is stable and boringly
> uniform?
>
> Looking at the power supplies and ground for occasional fast transients is
> also a good idea, but you probably have already gotten tired of doing
> that.
>
> An ugly possibility is that the reset is somehow caused by a bug that
> shows
> up only when an interrupt occurs at just the right time in a piece of
> vulnerable code. This could have the symptom you describe.
>
> I have found some of this kind of bug by careful code review.
>
> I have also sometimes been able to figure out ways to make the bug occur
> more often. Then the knowledge of what made the problem more frequent
> help
> me converge on the actual source of the problem.
>
> More notes below.
>
> Steve Russell
> Nohau Emulators
>
> At 02:31 PM 7/20/2005, you wrote:
>>We just can't seem to get rid to the resets.....we have a d60a based
>>board we use in an automotive ignition controller and every so often, we
>>get a reset. Is this microcontroller just very sensitive to EMI?? Is
>>there a software way to determine if the resets are coming from the COP
>>or from an external RESET?
>
> The external reset and power on reset vectors are the same, but the COP
> failure and clock monitor failure resets have different vectors, so you
> can
> easily detect whether they happen.
>
> While you are in the interrupt vectors, make sure that they are all set to
> point to code.
>
> I believe that pointing unexpected interrupts to an infinite loop is
> better
> than doing an RTI. An RTI may not reset the interrupt flag that is
> causing
> the interrupt, resulting in an interrupt loop. The infinite loop makes it
> easy to determine that there was an unexpected interrupt if you have a
> debugger connected.
>
> Flashing a light or making a noise will get you the information if you
> don't have a debugger connected.
>
>>I've tried everything from a 4 layer board to massive amounts of power
>>supply filtering, but nothing seems to work. There is an IGBT on the
>>board that is used in the ignition circuit, but the system doesn't reset
>>all that often....maybe once every 1/2 hour or so. Of course, even once
>>is too much.
>>
>>Any ideas?
>>
>>Stewart Prince
>>Professor, Mech Eng
>>CSUN
>>
>> >
>> >
>>
>>
>>
>>
>>Yahoo! Groups Links
>>
>>
>>
> >
>
> Yahoo! Groups Links >
>

Send instant messages to your online friends http://au.messenger.yahoo.com



I have my metrowerks vector file set up to jump to _startup for all
reset interrupts. What about jumping to a different point in the
program, say _main_cop for cop and _main_reset for reset? Then I could
set a different flag for each case?
S. Prince

Adrian Vos wrote:

>There is different reset vector location for a COP reset. I write the reset
>vector type to a variable that I can chekc later in my code to identify if
>it was a COP reset.
>
>-- Adrian
>
>----- Original Message -----
>From: "Steve Russell" <stever@stev...>
>To: <68HC12@68HC...>
>Sent: Thursday, July 21, 2005 8:26 AM
>Subject: Re: [68HC12] Getting unwanted resets >
>
>>Its always hard to give useful advice for this sort of problem. Most of
>>the things I can suggest will be things that you have already tried. I'll
>>try anyway. Maybe one suggestion will be something you haven't tried.
>>
>>The IGBT circuit is certainly a prime suspect. Could you arrange a test
>>where the only major difference from normal operation is that there is no
>>power to the IGBT circuit?
>>
>>An irregular MCU clock will cause some really mysterious effects. Can you
>>arrange to look at the ECLK signal to make sure it is stable and boringly
>>uniform?
>>
>>Looking at the power supplies and ground for occasional fast transients is
>>also a good idea, but you probably have already gotten tired of doing
>>that.
>>
>>An ugly possibility is that the reset is somehow caused by a bug that
>>shows
>>up only when an interrupt occurs at just the right time in a piece of
>>vulnerable code. This could have the symptom you describe.
>>
>>I have found some of this kind of bug by careful code review.
>>
>>I have also sometimes been able to figure out ways to make the bug occur
>>more often. Then the knowledge of what made the problem more frequent
>>help
>>me converge on the actual source of the problem.
>>
>>More notes below.
>>
>> Steve Russell
>> Nohau Emulators
>>
>>At 02:31 PM 7/20/2005, you wrote:
>>
>>
>>>We just can't seem to get rid to the resets.....we have a d60a based
>>>board we use in an automotive ignition controller and every so often, we
>>>get a reset. Is this microcontroller just very sensitive to EMI?? Is
>>>there a software way to determine if the resets are coming from the COP
>>>or from an external RESET?
>>>
>>>
>>The external reset and power on reset vectors are the same, but the COP
>>failure and clock monitor failure resets have different vectors, so you
>>can
>>easily detect whether they happen.
>>
>>While you are in the interrupt vectors, make sure that they are all set to
>>point to code.
>>
>>I believe that pointing unexpected interrupts to an infinite loop is
>>better
>>than doing an RTI. An RTI may not reset the interrupt flag that is
>>causing
>>the interrupt, resulting in an interrupt loop. The infinite loop makes it
>>easy to determine that there was an unexpected interrupt if you have a
>>debugger connected.
>>
>>Flashing a light or making a noise will get you the information if you
>>don't have a debugger connected.
>>
>>
>>
>>>I've tried everything from a 4 layer board to massive amounts of power
>>>supply filtering, but nothing seems to work. There is an IGBT on the
>>>board that is used in the ignition circuit, but the system doesn't reset
>>>all that often....maybe once every 1/2 hour or so. Of course, even once
>>>is too much.
>>>
>>>Any ideas?
>>>
>>>Stewart Prince
>>>Professor, Mech Eng
>>>CSUN
>>>
>>>
>>>
>>>>
>>>>
>>>
>>>
>>>Yahoo! Groups Links
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>Yahoo! Groups Links
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>Send instant messages to your online friends http://au.messenger.yahoo.com >
>Yahoo! Groups Links >




I have a seperate vector for COP reset, and in that vector, I set a
variable, and then jump to the main reset vector's location. Just make sure
you remove any code in the main reset vector that may clear the variable you
have set by clearing all RAM to 0 which is often the compiler default.

-- Adrian

----- Original Message -----
From: "Dr Stewart Prince" <sprince@spri...>
To: <68HC12@68HC...>
Sent: Thursday, July 21, 2005 11:46 AM
Subject: Re: [68HC12] Getting unwanted resets >I have my metrowerks vector file set up to jump to _startup for all
> reset interrupts. What about jumping to a different point in the
> program, say _main_cop for cop and _main_reset for reset? Then I could
> set a different flag for each case?
> S. Prince
>
> Adrian Vos wrote:
>
>>There is different reset vector location for a COP reset. I write the
>>reset
>>vector type to a variable that I can chekc later in my code to identify if
>>it was a COP reset.
>>
>>-- Adrian
>>
>>----- Original Message -----
>>From: "Steve Russell" <stever@stev...>
>>To: <68HC12@68HC...>
>>Sent: Thursday, July 21, 2005 8:26 AM
>>Subject: Re: [68HC12] Getting unwanted resets
>>
>>
>>
>>
>>>Its always hard to give useful advice for this sort of problem. Most of
>>>the things I can suggest will be things that you have already tried.
>>>I'll
>>>try anyway. Maybe one suggestion will be something you haven't tried.
>>>
>>>The IGBT circuit is certainly a prime suspect. Could you arrange a test
>>>where the only major difference from normal operation is that there is no
>>>power to the IGBT circuit?
>>>
>>>An irregular MCU clock will cause some really mysterious effects. Can
>>>you
>>>arrange to look at the ECLK signal to make sure it is stable and boringly
>>>uniform?
>>>
>>>Looking at the power supplies and ground for occasional fast transients
>>>is
>>>also a good idea, but you probably have already gotten tired of doing
>>>that.
>>>
>>>An ugly possibility is that the reset is somehow caused by a bug that
>>>shows
>>>up only when an interrupt occurs at just the right time in a piece of
>>>vulnerable code. This could have the symptom you describe.
>>>
>>>I have found some of this kind of bug by careful code review.
>>>
>>>I have also sometimes been able to figure out ways to make the bug occur
>>>more often. Then the knowledge of what made the problem more frequent
>>>help
>>>me converge on the actual source of the problem.
>>>
>>>More notes below.
>>>
>>> Steve Russell
>>> Nohau Emulators
>>>
>>>At 02:31 PM 7/20/2005, you wrote:
>>>
>>>
>>>>We just can't seem to get rid to the resets.....we have a d60a based
>>>>board we use in an automotive ignition controller and every so often, we
>>>>get a reset. Is this microcontroller just very sensitive to EMI?? Is
>>>>there a software way to determine if the resets are coming from the COP
>>>>or from an external RESET?
>>>>
>>>>
>>>The external reset and power on reset vectors are the same, but the COP
>>>failure and clock monitor failure resets have different vectors, so you
>>>can
>>>easily detect whether they happen.
>>>
>>>While you are in the interrupt vectors, make sure that they are all set
>>>to
>>>point to code.
>>>
>>>I believe that pointing unexpected interrupts to an infinite loop is
>>>better
>>>than doing an RTI. An RTI may not reset the interrupt flag that is
>>>causing
>>>the interrupt, resulting in an interrupt loop. The infinite loop makes
>>>it
>>>easy to determine that there was an unexpected interrupt if you have a
>>>debugger connected.
>>>
>>>Flashing a light or making a noise will get you the information if you
>>>don't have a debugger connected.
>>>
>>>
>>>
>>>>I've tried everything from a 4 layer board to massive amounts of power
>>>>supply filtering, but nothing seems to work. There is an IGBT on the
>>>>board that is used in the ignition circuit, but the system doesn't reset
>>>>all that often....maybe once every 1/2 hour or so. Of course, even once
>>>>is too much.
>>>>
>>>>Any ideas?
>>>>
>>>>Stewart Prince
>>>>Professor, Mech Eng
>>>>CSUN
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>Yahoo! Groups Links
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>Yahoo! Groups Links
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>Send instant messages to your online friends http://au.messenger.yahoo.com
>>
>>
>>
>>Yahoo! Groups Links
>>
>>
>>
>>
>>
>>
>>
>>
> >
>
> Yahoo! Groups Links >
>

Send instant messages to your online friends http://au.messenger.yahoo.com



Hello.

As already suggested by Adrian, I propose you to route all unimplemented
vectors to one single specific trap function. This trap function would lock
the cpu in a loop and display something on a LED bargraph, if you have one,
or any other visible, audible or measurable way.

Then you would be able to know the source vector even with hardware running
in standalone, i.e. without debugger.

As the COP is enabled by default on the MC9S12D60A, the COP should be
disabled in the locking loop, otherwise it will eventually always end up in
the COP trap.

Example for 2 vectors here below.

Regards,
Gilles //***************

#define PORTB (*((volatile unsigned char*)(0x0001)))
#define DDRB (*((volatile unsigned char*)(0x0003)))
#define COPCTL (*((volatile unsigned char*)(0x0016))) #define CLOCK_MONITOR_FAILURE_VECTOR 1
#define COP_FAILURE_VECTOR 2

interrupt CLOCK_MONITOR_FAILURE_VECTOR void my_clock_monitor_trap(void){
COPCTL = 0;
DDRB = 0xFF;
PORTB = ~CLOCK_MONITOR_FAILURE_VECTOR; /* display on LED's the vector
value */
while(1);
}

interrupt COP_FAILURE_VECTOR void my_cop_trap(void){
COPCTL = 0;
DDRB = 0xFF;
PORTB = ~COP_FAILURE_VECTOR;
while(1);
}

At 03:46 AM 7/21/2005, Dr Stewart Prince wrote:
>I have my metrowerks vector file set up to jump to _startup for all
>reset interrupts. What about jumping to a different point in the
>program, say _main_cop for cop and _main_reset for reset? Then I could
>set a different flag for each case?
>S. Prince
>
>Adrian Vos wrote:
>
> >There is different reset vector location for a COP reset. I write the reset
> >vector type to a variable that I can chekc later in my code to identify if
> >it was a COP reset.
> >
> >-- Adrian
> >
> >----- Original Message -----
> >From: "Steve Russell" <stever@stev...>
> >To: <68HC12@68HC...>
> >Sent: Thursday, July 21, 2005 8:26 AM
> >Subject: Re: [68HC12] Getting unwanted resets
> >
> >
> >
> >
> >>Its always hard to give useful advice for this sort of problem. Most of
> >>the things I can suggest will be things that you have already tried. I'll
> >>try anyway. Maybe one suggestion will be something you haven't tried.
> >>
> >>The IGBT circuit is certainly a prime suspect. Could you arrange a test
> >>where the only major difference from normal operation is that there is no
> >>power to the IGBT circuit?
> >>
> >>An irregular MCU clock will cause some really mysterious effects. Can you
> >>arrange to look at the ECLK signal to make sure it is stable and boringly
> >>uniform?
> >>
> >>Looking at the power supplies and ground for occasional fast transients is
> >>also a good idea, but you probably have already gotten tired of doing
> >>that.
> >>
> >>An ugly possibility is that the reset is somehow caused by a bug that
> >>shows
> >>up only when an interrupt occurs at just the right time in a piece of
> >>vulnerable code. This could have the symptom you describe.
> >>
> >>I have found some of this kind of bug by careful code review.
> >>
> >>I have also sometimes been able to figure out ways to make the bug occur
> >>more often. Then the knowledge of what made the problem more frequent
> >>help
> >>me converge on the actual source of the problem.
> >>
> >>More notes below.
> >>
> >> Steve Russell
> >> Nohau Emulators
> >>
> >>At 02:31 PM 7/20/2005, you wrote:
> >>
> >>
> >>>We just can't seem to get rid to the resets.....we have a d60a based
> >>>board we use in an automotive ignition controller and every so often, we
> >>>get a reset. Is this microcontroller just very sensitive to EMI?? Is
> >>>there a software way to determine if the resets are coming from the COP
> >>>or from an external RESET?
> >>>
> >>>
> >>The external reset and power on reset vectors are the same, but the COP
> >>failure and clock monitor failure resets have different vectors, so you
> >>can
> >>easily detect whether they happen.
> >>
> >>While you are in the interrupt vectors, make sure that they are all set to
> >>point to code.
> >>
> >>I believe that pointing unexpected interrupts to an infinite loop is
> >>better
> >>than doing an RTI. An RTI may not reset the interrupt flag that is
> >>causing
> >>the interrupt, resulting in an interrupt loop. The infinite loop makes it
> >>easy to determine that there was an unexpected interrupt if you have a
> >>debugger connected.
> >>
> >>Flashing a light or making a noise will get you the information if you
> >>don't have a debugger connected.
> >>
> >>
> >>
> >>>I've tried everything from a 4 layer board to massive amounts of power
> >>>supply filtering, but nothing seems to work. There is an IGBT on the
> >>>board that is used in the ignition circuit, but the system doesn't reset
> >>>all that often....maybe once every 1/2 hour or so. Of course, even once
> >>>is too much.
> >>>
> >>>Any ideas?
> >>>
> >>>Stewart Prince
> >>>Professor, Mech Eng
> >>>CSUN
> >>>
> >>>
> >>>
> >>>>
> >>>>
> >>>
> >>>
> >>>Yahoo! Groups Links
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >>Yahoo! Groups Links
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >Send instant messages to your online friends http://au.messenger.yahoo.com
> >
> >
> >
> >Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
>Yahoo! Groups Links >
>




Gilles/All: Thanks for answering.

Good idea. What if I wanted to vector to these routines, then jump to
the main subroutine? That way, I could see what is happening on port A
and then continue running the program.

My question is: when using C and metrowerks codewarrior, the vector
table is set up in the .prm file-when an interrupt goes off, the program
vectors to the proper interrupt subroutine , some code is executed, and
a return from interrupt is generated. So, if you are in the middle of a
subroutine, the interrupt is acknowledged, and you return back to the
same place before the interrupt occurred. I'm assuming the return from
interrupt is taken care of behind the scenes because the routines you
show below don't contain rti. Right now, I am vectoring to _STARTUP
when the COP , CLOCK MONITOR, AND EXTERNAL RESET interrupts occur. So,
this means when a COP or external reset occurs while I am executing my
program, the stack is pushed, the program vectors to _STARTUP which
then jumps to MAIN. When does the interrupt clearing take place?
Somehow, the interrupt bit must be cleared to pop the stack properly.

Here's what I want to do:

* External Reset causes vector to _startup that jumps to main.
Program functions normally.
* COP vectors to COP_FAILURE_VECTOR that performs the routine below,
but instead of looping, jumps to MAIN.

How can this be done in C with the .prm file?

Thanks in advance
Stewart Prince

Gilles Blanquin wrote:

>Hello.
>
>As already suggested by Adrian, I propose you to route all unimplemented
>vectors to one single specific trap function. This trap function would lock
>the cpu in a loop and display something on a LED bargraph, if you have one,
>or any other visible, audible or measurable way.
>
>Then you would be able to know the source vector even with hardware running
>in standalone, i.e. without debugger.
>
>As the COP is enabled by default on the MC9S12D60A, the COP should be
>disabled in the locking loop, otherwise it will eventually always end up in
>the COP trap.
>
>Example for 2 vectors here below.
>
>Regards,
>Gilles >//***************
>
>#define PORTB (*((volatile unsigned char*)(0x0001)))
>#define DDRB (*((volatile unsigned char*)(0x0003)))
>#define COPCTL (*((volatile unsigned char*)(0x0016))) >#define CLOCK_MONITOR_FAILURE_VECTOR 1
>#define COP_FAILURE_VECTOR 2
>
>interrupt CLOCK_MONITOR_FAILURE_VECTOR void my_clock_monitor_trap(void){
> COPCTL = 0;
> DDRB = 0xFF;
> PORTB = ~CLOCK_MONITOR_FAILURE_VECTOR; /* display on LED's the vector
>value */
> while(1);
>}
>
>interrupt COP_FAILURE_VECTOR void my_cop_trap(void){
> COPCTL = 0;
> DDRB = 0xFF;
> PORTB = ~COP_FAILURE_VECTOR;
> while(1);
>} >
>
>At 03:46 AM 7/21/2005, Dr Stewart Prince wrote: >>I have my metrowerks vector file set up to jump to _startup for all
>>reset interrupts. What about jumping to a different point in the
>>program, say _main_cop for cop and _main_reset for reset? Then I could
>>set a different flag for each case?
>>S. Prince
>>
>>Adrian Vos wrote:
>>
>>
>>
>>>There is different reset vector location for a COP reset. I write the reset
>>>vector type to a variable that I can chekc later in my code to identify if
>>>it was a COP reset.
>>>
>>>-- Adrian
>>>
>>>----- Original Message -----
>>>From: "Steve Russell" <stever@stev...>
>>>To: <68HC12@68HC...>
>>>Sent: Thursday, July 21, 2005 8:26 AM
>>>Subject: Re: [68HC12] Getting unwanted resets
>>>
>>>
>>>
>>>
>>>
>>>
>>>>Its always hard to give useful advice for this sort of problem. Most of
>>>>the things I can suggest will be things that you have already tried. I'll
>>>>try anyway. Maybe one suggestion will be something you haven't tried.
>>>>
>>>>The IGBT circuit is certainly a prime suspect. Could you arrange a test
>>>>where the only major difference from normal operation is that there is no
>>>>power to the IGBT circuit?
>>>>
>>>>An irregular MCU clock will cause some really mysterious effects. Can you
>>>>arrange to look at the ECLK signal to make sure it is stable and boringly
>>>>uniform?
>>>>
>>>>Looking at the power supplies and ground for occasional fast transients is
>>>>also a good idea, but you probably have already gotten tired of doing
>>>>that.
>>>>
>>>>An ugly possibility is that the reset is somehow caused by a bug that
>>>>shows
>>>>up only when an interrupt occurs at just the right time in a piece of
>>>>vulnerable code. This could have the symptom you describe.
>>>>
>>>>I have found some of this kind of bug by careful code review.
>>>>
>>>>I have also sometimes been able to figure out ways to make the bug occur
>>>>more often. Then the knowledge of what made the problem more frequent
>>>>help
>>>>me converge on the actual source of the problem.
>>>>
>>>>More notes below.
>>>>
>>>> Steve Russell
>>>> Nohau Emulators
>>>>
>>>>At 02:31 PM 7/20/2005, you wrote:
>>>>
>>>>
>>>>
>>>>
>>>>>We just can't seem to get rid to the resets.....we have a d60a based
>>>>>board we use in an automotive ignition controller and every so often, we
>>>>>get a reset. Is this microcontroller just very sensitive to EMI?? Is
>>>>>there a software way to determine if the resets are coming from the COP
>>>>>or from an external RESET?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>The external reset and power on reset vectors are the same, but the COP
>>>>failure and clock monitor failure resets have different vectors, so you
>>>>can
>>>>easily detect whether they happen.
>>>>
>>>>While you are in the interrupt vectors, make sure that they are all set to
>>>>point to code.
>>>>
>>>>I believe that pointing unexpected interrupts to an infinite loop is
>>>>better
>>>>than doing an RTI. An RTI may not reset the interrupt flag that is
>>>>causing
>>>>the interrupt, resulting in an interrupt loop. The infinite loop makes it
>>>>easy to determine that there was an unexpected interrupt if you have a
>>>>debugger connected.
>>>>
>>>>Flashing a light or making a noise will get you the information if you
>>>>don't have a debugger connected.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>I've tried everything from a 4 layer board to massive amounts of power
>>>>>supply filtering, but nothing seems to work. There is an IGBT on the
>>>>>board that is used in the ignition circuit, but the system doesn't reset
>>>>>all that often....maybe once every 1/2 hour or so. Of course, even once
>>>>>is too much.
>>>>>
>>>>>Any ideas?
>>>>>
>>>>>Stewart Prince
>>>>>Professor, Mech Eng
>>>>>CSUN
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>Yahoo! Groups Links
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>Yahoo! Groups Links
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>Send instant messages to your online friends http://au.messenger.yahoo.com
>>>
>>>
>>>
>>>Yahoo! Groups Links
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>>Yahoo! Groups Links
>>
>>
>>
>>
>>
> >
>
>Yahoo! Groups Links >




Stuart,

Gilles routines actually do not return ever. So they dont clean up at
all. If they would return, the compiler would end them with a RTI
because of the interrupt keyword.
If you want to restart the app from your COP handler, just jump to _Startup.
There are multiple reasons why you do not need to cleanup the stack.
First, _Startup will just load a new SP value anyway and start with an
empty stack.
And second, I dont think that the COP exception does actually stack the
context. There is just no way/reason to ever undo a COP reset, and when
for whatever reason the COP is happening, the stack may be just corrupt
(there was a reason why the COP was not feed, after all).

Also note that you should redirect ALL vectors, not just the ones you
think they could ever happen. For most of then, an endless loop (and
maybe something which helps you in debugging) is just fine. Just let the
COP do the reset.

Daniel Dr Stewart Prince wrote:
> Gilles/All: Thanks for answering.
>
> Good idea. What if I wanted to vector to these routines, then jump to
> the main subroutine? That way, I could see what is happening on port A
> and then continue running the program.
>
> My question is: when using C and metrowerks codewarrior, the vector
> table is set up in the .prm file-when an interrupt goes off, the program
> vectors to the proper interrupt subroutine , some code is executed, and
> a return from interrupt is generated. So, if you are in the middle of a
> subroutine, the interrupt is acknowledged, and you return back to the
> same place before the interrupt occurred. I'm assuming the return from
> interrupt is taken care of behind the scenes because the routines you
> show below don't contain rti. Right now, I am vectoring to _STARTUP
> when the COP , CLOCK MONITOR, AND EXTERNAL RESET interrupts occur. So,
> this means when a COP or external reset occurs while I am executing my
> program, the stack is pushed, the program vectors to _STARTUP which
> then jumps to MAIN. When does the interrupt clearing take place?
> Somehow, the interrupt bit must be cleared to pop the stack properly.
>
> Here's what I want to do:
>
> * External Reset causes vector to _startup that jumps to main.
> Program functions normally.
> * COP vectors to COP_FAILURE_VECTOR that performs the routine below,
> but instead of looping, jumps to MAIN.
>
> How can this be done in C with the .prm file?
>
> Thanks in advance
> Stewart Prince
>
> Gilles Blanquin wrote: >>Hello.
>>
>>As already suggested by Adrian, I propose you to route all unimplemented
>>vectors to one single specific trap function. This trap function would lock
>>the cpu in a loop and display something on a LED bargraph, if you have one,
>>or any other visible, audible or measurable way.
>>
>>Then you would be able to know the source vector even with hardware running
>>in standalone, i.e. without debugger.
>>
>>As the COP is enabled by default on the MC9S12D60A, the COP should be
>>disabled in the locking loop, otherwise it will eventually always end up in
>>the COP trap.
>>
>>Example for 2 vectors here below.
>>
>>Regards,
>>Gilles
>>
>>
>>//***************
>>
>>#define PORTB (*((volatile unsigned char*)(0x0001)))
>>#define DDRB (*((volatile unsigned char*)(0x0003)))
>>#define COPCTL (*((volatile unsigned char*)(0x0016)))
>>
>>
>>#define CLOCK_MONITOR_FAILURE_VECTOR 1
>>#define COP_FAILURE_VECTOR 2
>>
>>interrupt CLOCK_MONITOR_FAILURE_VECTOR void my_clock_monitor_trap(void){
>> COPCTL = 0;
>> DDRB = 0xFF;
>> PORTB = ~CLOCK_MONITOR_FAILURE_VECTOR; /* display on LED's the vector
>>value */
>> while(1);
>>}
>>
>>interrupt COP_FAILURE_VECTOR void my_cop_trap(void){
>> COPCTL = 0;
>> DDRB = 0xFF;
>> PORTB = ~COP_FAILURE_VECTOR;
>> while(1);
>>}
>>
>>
>>
>>
>>At 03:46 AM 7/21/2005, Dr Stewart Prince wrote:
>>
>>
>>
>>>I have my metrowerks vector file set up to jump to _startup for all
>>>reset interrupts. What about jumping to a different point in the
>>>program, say _main_cop for cop and _main_reset for reset? Then I could
>>>set a different flag for each case?
>>>S. Prince
>>>
>>>Adrian Vos wrote:
>>>
>>>
>>>
>>>
>>>>There is different reset vector location for a COP reset. I write the reset
>>>>vector type to a variable that I can chekc later in my code to identify if
>>>>it was a COP reset.
>>>>
>>>>-- Adrian
>>>>
>>>>----- Original Message -----
>>>>From: "Steve Russell" <stever@stev...>
>>>>To: <68HC12@68HC...>
>>>>Sent: Thursday, July 21, 2005 8:26 AM
>>>>Subject: Re: [68HC12] Getting unwanted resets
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>Its always hard to give useful advice for this sort of problem. Most of
>>>>>the things I can suggest will be things that you have already tried. I'll
>>>>>try anyway. Maybe one suggestion will be something you haven't tried.
>>>>>
>>>>>The IGBT circuit is certainly a prime suspect. Could you arrange a test
>>>>>where the only major difference from normal operation is that there is no
>>>>>power to the IGBT circuit?
>>>>>
>>>>>An irregular MCU clock will cause some really mysterious effects. Can you
>>>>>arrange to look at the ECLK signal to make sure it is stable and boringly
>>>>>uniform?
>>>>>
>>>>>Looking at the power supplies and ground for occasional fast transients is
>>>>>also a good idea, but you probably have already gotten tired of doing
>>>>>that.
>>>>>
>>>>>An ugly possibility is that the reset is somehow caused by a bug that
>>>>>shows
>>>>>up only when an interrupt occurs at just the right time in a piece of
>>>>>vulnerable code. This could have the symptom you describe.
>>>>>
>>>>>I have found some of this kind of bug by careful code review.
>>>>>
>>>>>I have also sometimes been able to figure out ways to make the bug occur
>>>>>more often. Then the knowledge of what made the problem more frequent
>>>>>help
>>>>>me converge on the actual source of the problem.
>>>>>
>>>>>More notes below.
>>>>>
>>>>> Steve Russell
>>>>> Nohau Emulators
>>>>>
>>>>>At 02:31 PM 7/20/2005, you wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>We just can't seem to get rid to the resets.....we have a d60a based
>>>>>>board we use in an automotive ignition controller and every so often, we
>>>>>>get a reset. Is this microcontroller just very sensitive to EMI?? Is
>>>>>>there a software way to determine if the resets are coming from the COP
>>>>>>or from an external RESET?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>The external reset and power on reset vectors are the same, but the COP
>>>>>failure and clock monitor failure resets have different vectors, so you
>>>>>can
>>>>>easily detect whether they happen.
>>>>>
>>>>>While you are in the interrupt vectors, make sure that they are all set to
>>>>>point to code.
>>>>>
>>>>>I believe that pointing unexpected interrupts to an infinite loop is
>>>>>better
>>>>>than doing an RTI. An RTI may not reset the interrupt flag that is
>>>>>causing
>>>>>the interrupt, resulting in an interrupt loop. The infinite loop makes it
>>>>>easy to determine that there was an unexpected interrupt if you have a
>>>>>debugger connected.
>>>>>
>>>>>Flashing a light or making a noise will get you the information if you
>>>>>don't have a debugger connected.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>I've tried everything from a 4 layer board to massive amounts of power
>>>>>>supply filtering, but nothing seems to work. There is an IGBT on the
>>>>>>board that is used in the ignition circuit, but the system doesn't reset
>>>>>>all that often....maybe once every 1/2 hour or so. Of course, even once
>>>>>>is too much.
>>>>>>
>>>>>>Any ideas?
>>>>>>
>>>>>>Stewart Prince
>>>>>>Professor, Mech Eng
>>>>>>CSUN
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>Yahoo! Groups Links
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>Yahoo! Groups Links
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>Send instant messages to your online friends http://au.messenger.yahoo.com
>>>>
>>>>
>>>>
>>>>Yahoo! Groups Links
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>Yahoo! Groups Links
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>Yahoo! Groups Links
>>
>>
>>
>>
>>
>>
>>
>>
> > Yahoo! Groups Links >
>




Dan
Understood, but in this case the application must continue to run: I
want it to run for many hours and document how many COPs, and RESETS
occur-that is why I must have the return in there.

So, what I really want to do is to jump to an intermediate subroutine,
then set a flag recording the number of COPs then jump to _Startup. Is
this possible?

Thanks
Stewart Prince

Daniel Friededrich wrote:

>Stuart,
>
>Gilles routines actually do not return ever. So they dont clean up at
>all. If they would return, the compiler would end them with a RTI
>because of the interrupt keyword.
>If you want to restart the app from your COP handler, just jump to _Startup.
>There are multiple reasons why you do not need to cleanup the stack.
>First, _Startup will just load a new SP value anyway and start with an
>empty stack.
>And second, I dont think that the COP exception does actually stack the
>context. There is just no way/reason to ever undo a COP reset, and when
>for whatever reason the COP is happening, the stack may be just corrupt
>(there was a reason why the COP was not feed, after all).
>
>Also note that you should redirect ALL vectors, not just the ones you
>think they could ever happen. For most of then, an endless loop (and
>maybe something which helps you in debugging) is just fine. Just let the
>COP do the reset.
>
>Daniel >Dr Stewart Prince wrote: >>Gilles/All: Thanks for answering.
>>
>>Good idea. What if I wanted to vector to these routines, then jump to
>>the main subroutine? That way, I could see what is happening on port A
>>and then continue running the program.
>>
>>My question is: when using C and metrowerks codewarrior, the vector
>>table is set up in the .prm file-when an interrupt goes off, the program
>>vectors to the proper interrupt subroutine , some code is executed, and
>>a return from interrupt is generated. So, if you are in the middle of a
>>subroutine, the interrupt is acknowledged, and you return back to the
>>same place before the interrupt occurred. I'm assuming the return from
>>interrupt is taken care of behind the scenes because the routines you
>>show below don't contain rti. Right now, I am vectoring to _STARTUP
>>when the COP , CLOCK MONITOR, AND EXTERNAL RESET interrupts occur. So,
>>this means when a COP or external reset occurs while I am executing my
>>program, the stack is pushed, the program vectors to _STARTUP which
>>then jumps to MAIN. When does the interrupt clearing take place?
>>Somehow, the interrupt bit must be cleared to pop the stack properly.
>>
>>Here's what I want to do:
>>
>> * External Reset causes vector to _startup that jumps to main.
>> Program functions normally.
>> * COP vectors to COP_FAILURE_VECTOR that performs the routine below,
>> but instead of looping, jumps to MAIN.
>>
>>How can this be done in C with the .prm file?
>>
>>Thanks in advance
>>Stewart Prince
>>
>>Gilles Blanquin wrote:
>>
>>
>>
>>
>>>Hello.
>>>
>>>As already suggested by Adrian, I propose you to route all unimplemented
>>>vectors to one single specific trap function. This trap function would lock
>>>the cpu in a loop and display something on a LED bargraph, if you have one,
>>>or any other visible, audible or measurable way.
>>>
>>>Then you would be able to know the source vector even with hardware running
>>>in standalone, i.e. without debugger.
>>>
>>>As the COP is enabled by default on the MC9S12D60A, the COP should be
>>>disabled in the locking loop, otherwise it will eventually always end up in
>>>the COP trap.
>>>
>>>Example for 2 vectors here below.
>>>
>>>Regards,
>>>Gilles
>>>
>>>
>>>//***************
>>>
>>>#define PORTB (*((volatile unsigned char*)(0x0001)))
>>>#define DDRB (*((volatile unsigned char*)(0x0003)))
>>>#define COPCTL (*((volatile unsigned char*)(0x0016)))
>>>
>>>
>>>#define CLOCK_MONITOR_FAILURE_VECTOR 1
>>>#define COP_FAILURE_VECTOR 2
>>>
>>>interrupt CLOCK_MONITOR_FAILURE_VECTOR void my_clock_monitor_trap(void){
>>> COPCTL = 0;
>>> DDRB = 0xFF;
>>> PORTB = ~CLOCK_MONITOR_FAILURE_VECTOR; /* display on LED's the vector
>>>value */
>>> while(1);
>>>}
>>>
>>>interrupt COP_FAILURE_VECTOR void my_cop_trap(void){
>>> COPCTL = 0;
>>> DDRB = 0xFF;
>>> PORTB = ~COP_FAILURE_VECTOR;
>>> while(1);
>>>}
>>>
>>>
>>>
>>>
>>>At 03:46 AM 7/21/2005, Dr Stewart Prince wrote:
>>>
>>>
>>>
>>>
>>>
>>>>I have my metrowerks vector file set up to jump to _startup for all
>>>>reset interrupts. What about jumping to a different point in the
>>>>program, say _main_cop for cop and _main_reset for reset? Then I could
>>>>set a different flag for each case?
>>>>S. Prince
>>>>
>>>>Adrian Vos wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>There is different reset vector location for a COP reset. I write the reset
>>>>>vector type to a variable that I can chekc later in my code to identify if
>>>>>it was a COP reset.
>>>>>
>>>>>-- Adrian
>>>>>
>>>>>----- Original Message -----
>>>>>From: "Steve Russell" <stever@stev...>
>>>>>To: <68HC12@68HC...>
>>>>>Sent: Thursday, July 21, 2005 8:26 AM
>>>>>Subject: Re: [68HC12] Getting unwanted resets
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Its always hard to give useful advice for this sort of problem. Most of
>>>>>>the things I can suggest will be things that you have already tried. I'll
>>>>>>try anyway. Maybe one suggestion will be something you haven't tried.
>>>>>>
>>>>>>The IGBT circuit is certainly a prime suspect. Could you arrange a test
>>>>>>where the only major difference from normal operation is that there is no
>>>>>>power to the IGBT circuit?
>>>>>>
>>>>>>An irregular MCU clock will cause some really mysterious effects. Can you
>>>>>>arrange to look at the ECLK signal to make sure it is stable and boringly
>>>>>>uniform?
>>>>>>
>>>>>>Looking at the power supplies and ground for occasional fast transients is
>>>>>>also a good idea, but you probably have already gotten tired of doing
>>>>>>that.
>>>>>>
>>>>>>An ugly possibility is that the reset is somehow caused by a bug that
>>>>>>shows
>>>>>>up only when an interrupt occurs at just the right time in a piece of
>>>>>>vulnerable code. This could have the symptom you describe.
>>>>>>
>>>>>>I have found some of this kind of bug by careful code review.
>>>>>>
>>>>>>I have also sometimes been able to figure out ways to make the bug occur
>>>>>>more often. Then the knowledge of what made the problem more frequent
>>>>>>help
>>>>>>me converge on the actual source of the problem.
>>>>>>
>>>>>>More notes below.
>>>>>>
>>>>>> Steve Russell
>>>>>> Nohau Emulators
>>>>>>
>>>>>>At 02:31 PM 7/20/2005, you wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>We just can't seem to get rid to the resets.....we have a d60a based
>>>>>>>board we use in an automotive ignition controller and every so often, we
>>>>>>>get a reset. Is this microcontroller just very sensitive to EMI?? Is
>>>>>>>there a software way to determine if the resets are coming from the COP
>>>>>>>or from an external RESET?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>The external reset and power on reset vectors are the same, but the COP
>>>>>>failure and clock monitor failure resets have different vectors, so you
>>>>>>can
>>>>>>easily detect whether they happen.
>>>>>>
>>>>>>While you are in the interrupt vectors, make sure that they are all set to
>>>>>>point to code.
>>>>>>
>>>>>>I believe that pointing unexpected interrupts to an infinite loop is
>>>>>>better
>>>>>>than doing an RTI. An RTI may not reset the interrupt flag that is
>>>>>>causing
>>>>>>the interrupt, resulting in an interrupt loop. The infinite loop makes it
>>>>>>easy to determine that there was an unexpected interrupt if you have a
>>>>>>debugger connected.
>>>>>>
>>>>>>Flashing a light or making a noise will get you the information if you
>>>>>>don't have a debugger connected.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>I've tried everything from a 4 layer board to massive amounts of power
>>>>>>>supply filtering, but nothing seems to work. There is an IGBT on the
>>>>>>>board that is used in the ignition circuit, but the system doesn't reset
>>>>>>>all that often....maybe once every 1/2 hour or so. Of course, even once
>>>>>>>is too much.
>>>>>>>
>>>>>>>Any ideas?
>>>>>>>
>>>>>>>Stewart Prince
>>>>>>>Professor, Mech Eng
>>>>>>>CSUN
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>Yahoo! Groups Links
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>Yahoo! Groups Links
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>Send instant messages to your online friends http://au.messenger.yahoo.com
>>>>>
>>>>>
>>>>>
>>>>>Yahoo! Groups Links
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>Yahoo! Groups Links
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>Yahoo! Groups Links
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>>
>>Yahoo! Groups Links
>>
>>
>>
>>
>>
>>
>>
>>
> >
>
>Yahoo! Groups Links >




Adrian
This is exactly what I want to do. Can you pls respond with what this
looks like in terms of code and the .prm file?

Thanks in advance

Stewart Prince

Adrian Vos wrote:

>I have a seperate vector for COP reset, and in that vector, I set a
>variable, and then jump to the main reset vector's location. Just make sure
>you remove any code in the main reset vector that may clear the variable you
>have set by clearing all RAM to 0 which is often the compiler default.
>
>-- Adrian
>
>----- Original Message -----
>From: "Dr Stewart Prince" <sprince@spri...>
>To: <68HC12@68HC...>
>Sent: Thursday, July 21, 2005 11:46 AM
>Subject: Re: [68HC12] Getting unwanted resets >
>
>>I have my metrowerks vector file set up to jump to _startup for all
>>reset interrupts. What about jumping to a different point in the
>>program, say _main_cop for cop and _main_reset for reset? Then I could
>>set a different flag for each case?
>>S. Prince
>>
>>Adrian Vos wrote:
>>
>>
>>
>>>There is different reset vector location for a COP reset. I write the
>>>reset
>>>vector type to a variable that I can chekc later in my code to identify if
>>>it was a COP reset.
>>>
>>>-- Adrian
>>>
>>>----- Original Message -----
>>>From: "Steve Russell" <stever@stev...>
>>>To: <68HC12@68HC...>
>>>Sent: Thursday, July 21, 2005 8:26 AM
>>>Subject: Re: [68HC12] Getting unwanted resets
>>>
>>>
>>>
>>>
>>>
>>>
>>>>Its always hard to give useful advice for this sort of problem. Most of
>>>>the things I can suggest will be things that you have already tried.
>>>>I'll
>>>>try anyway. Maybe one suggestion will be something you haven't tried.
>>>>
>>>>The IGBT circuit is certainly a prime suspect. Could you arrange a test
>>>>where the only major difference from normal operation is that there is no
>>>>power to the IGBT circuit?
>>>>
>>>>An irregular MCU clock will cause some really mysterious effects. Can
>>>>you
>>>>arrange to look at the ECLK signal to make sure it is stable and boringly
>>>>uniform?
>>>>
>>>>Looking at the power supplies and ground for occasional fast transients
>>>>is
>>>>also a good idea, but you probably have already gotten tired of doing
>>>>that.
>>>>
>>>>An ugly possibility is that the reset is somehow caused by a bug that
>>>>shows
>>>>up only when an interrupt occurs at just the right time in a piece of
>>>>vulnerable code. This could have the symptom you describe.
>>>>
>>>>I have found some of this kind of bug by careful code review.
>>>>
>>>>I have also sometimes been able to figure out ways to make the bug occur
>>>>more often. Then the knowledge of what made the problem more frequent
>>>>help
>>>>me converge on the actual source of the problem.
>>>>
>>>>More notes below.
>>>>
>>>> Steve Russell
>>>> Nohau Emulators
>>>>
>>>>At 02:31 PM 7/20/2005, you wrote:
>>>>
>>>>
>>>>
>>>>
>>>>>We just can't seem to get rid to the resets.....we have a d60a based
>>>>>board we use in an automotive ignition controller and every so often, we
>>>>>get a reset. Is this microcontroller just very sensitive to EMI?? Is
>>>>>there a software way to determine if the resets are coming from the COP
>>>>>or from an external RESET?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>The external reset and power on reset vectors are the same, but the COP
>>>>failure and clock monitor failure resets have different vectors, so you
>>>>can
>>>>easily detect whether they happen.
>>>>
>>>>While you are in the interrupt vectors, make sure that they are all set
>>>>to
>>>>point to code.
>>>>
>>>>I believe that pointing unexpected interrupts to an infinite loop is
>>>>better
>>>>than doing an RTI. An RTI may not reset the interrupt flag that is
>>>>causing
>>>>the interrupt, resulting in an interrupt loop. The infinite loop makes
>>>>it
>>>>easy to determine that there was an unexpected interrupt if you have a
>>>>debugger connected.
>>>>
>>>>Flashing a light or making a noise will get you the information if you
>>>>don't have a debugger connected.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>I've tried everything from a 4 layer board to massive amounts of power
>>>>>supply filtering, but nothing seems to work. There is an IGBT on the
>>>>>board that is used in the ignition circuit, but the system doesn't reset
>>>>>all that often....maybe once every 1/2 hour or so. Of course, even once
>>>>>is too much.
>>>>>
>>>>>Any ideas?
>>>>>
>>>>>Stewart Prince
>>>>>Professor, Mech Eng
>>>>>CSUN
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>Yahoo! Groups Links
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>Yahoo! Groups Links
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>Send instant messages to your online friends http://au.messenger.yahoo.com
>>>
>>>
>>>
>>>Yahoo! Groups Links
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>>Yahoo! Groups Links
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>Send instant messages to your online friends http://au.messenger.yahoo.com >
>Yahoo! Groups Links >