----- Original Message -----
From:
To: <6...>
Sent: Friday, November 17, 2006 5:37 AM
Subject: RE: [68HC12] Deferred Service Routine
> Hello Amit,
>
> Another solution I can propose, see how do you find it.
>
> You can have one volatile counter. Each time you visit the ISR increment
> this counter. You have another cyclic function (frequency you can define
> based on your design) where you check for this counter. If the
> difference between counter value is high enough you can detect
> malfunction and shut down the ISR.

Suppose due malfunction there is a continuous ~kHz-MHz oscilation on input
capture pin. IC ISR may execute "nonstop", enter-exit-enter-exit.
If your cyclic function is an another ISR, then it should have higher
priority than IC ISR. Else your cyclic ISR may have no chance to execute.
And your volatile counter shouldn't but can overflow.
If your cyclic function is a part of main thread or is some RTOS thread,
then, due nonstop IC ISR
enterISR-exitISR-execute_a_couple_of_main()_instructions-enterISR, your task
will slowdown by orders. COP can fire sooner than you will be able to detect
malfunction. It may be better to detect this sort of malfunction in IC
interrupt, check the TCNT difference between two IC events. Of course timer
overflows should be taken into account, else your detector may give false
alarms. I think it's better to filter what is out of specs and detect if
it's out of specs.

Edward

>
> But one care you have to take is due to nesting of ISR you don't run
> away from the stack. So your cyclic function should be frequent enough.
>
> OR another solution could be alter your layout and give vehicle speed
> input to a frequency input of your processor (if you have any). So you
> don't have any ISR triggered. Check this frequency in a cyclic function.
>
> regards,
> Nitesh.
>
> ________________________________
>
> From: 6... [mailto:6...] On Behalf
> Of Amit Gupta
> Sent: Thursday, November 16, 2006 4:50 PM
> To: k...@ar.fi.lt; 6...
> Subject: [68HC12] Deferred Service Routine
>
> Edward and all
>
> Yeah they are two different question which I mistakingly merged in one.
>
> Well Now, I am interested in second question - malfunctioning part. I do
> not understand how the faster MCU willl help in this case, only the
> execution rate (MIPS rate increase) which is not the result for
> malfunctioning.
>
> Let me tell you the situation - I am using an Input capture interrupt to
> measure vehicle speed - number to edge triggered pulses will result in
> generating an interrupt. Now assume that due to some drivers mistake- he
> overspeed the vehicle - then speed and number of pulses received at port
> pin are too high. This is a real scearion failure - mal functioning
> issue. Now even if I reenable the Interrupt in the end of ISR, this will
> actually not solve my problem.
>
> What can be possible solutions :-
>
> 1. Either I use a user variable which actually measures like how many
> times the Interrupt is taking place in aminute(or some time), so that if
> an interrupt is occuring at very high rate, then I will completely
> disable the interrupt.
>
> 2. Or I use some time of preemptive RTOS - or if not, then have an OS
> (by making it myself) above the processor level layer which actually
> prioritize the complate component (measuring vehicle speed is just a
> part of it). Something like Priority inversion can take place if some
> process is continously running.
>
> This is just in thinking process. Kindly elaborate these solutiion
> possible. What I feel practically we have second type solution more
> prominent.
>
> Thanks & Regards
>
> Amit
>
> -----Original Message-----
> From: k...@ar.fi.lt
> Sent: Thu, 16 Nov 2006 12:17:55 +0200
> To: 6...































'


''





'










'











'

'

























&





























'

























'



























<









'
























Start a New Thread

Hello Amit,

Another solution I can propose, see how do you find it.

You can have one volatile counter. Each time you visit the ISR increment
this counter. You have another cyclic function (frequency you can define
based on your design) where you check for this counter. If the
difference between counter value is high enough you can detect
malfunction and shut down the ISR.

But one care you have to take is due to nesting of ISR you don't run
away from the stack. So your cyclic function should be frequent enough.

OR another solution could be alter your layout and give vehicle speed
input to a frequency input of your processor (if you have any). So you
don't have any ISR triggered. Check this frequency in a cyclic function.

regards,
Nitesh.

________________________________

From: 6... [mailto:6...] On Behalf
Of Amit Gupta
Sent: Thursday, November 16, 2006 4:50 PM
To: k...@ar.fi.lt; 6...
Subject: [68HC12] Deferred Service Routine

Edward and all

Yeah they are two different question which I mistakingly merged in one.

Well Now, I am interested in second question - malfunctioning part. I do
not understand how the faster MCU willl help in this case, only the
execution rate (MIPS rate increase) which is not the result for
malfunctioning.

Let me tell you the situation - I am using an Input capture interrupt to
measure vehicle speed - number to edge triggered pulses will result in
generating an interrupt. Now assume that due to some drivers mistake- he
overspeed the vehicle - then speed and number of pulses received at port
pin are too high. This is a real scearion failure - mal functioning
issue. Now even if I reenable the Interrupt in the end of ISR, this will
actually not solve my problem.

What can be possible solutions :-

1. Either I use a user variable which actually measures like how many
times the Interrupt is taking place in aminute(or some time), so that if
an interrupt is occuring at very high rate, then I will completely
disable the interrupt.

2. Or I use some time of preemptive RTOS - or if not, then have an OS
(by making it myself) above the processor level layer which actually
prioritize the complate component (measuring vehicle speed is just a
part of it). Something like Priority inversion can take place if some
process is continously running.

This is just in thinking process. Kindly elaborate these solutiion
possible. What I feel practically we have second type solution more
prominent.

Thanks & Regards

Amit

-----Original Message-----
From: k...@ar.fi.lt
Sent: Thu, 16 Nov 2006 12:17:55 +0200
To: 6...































'


''





'










'











'

'

























&































'



























'



























<









'






















Start a New Thread

Edward and all

Yeah they are two different question which I mistakingly merged in one.

Well Now, I am interested in second question - malfunctioning part. I do not understand how the faster MCU willl help in this case, only the execution rate (MIPS rate increase) which is not the result for malfunctioning.

Let me tell you the situation - I am using an Input capture interrupt to measure vehicle speed - number to edge triggered pulses will result in generating an interrupt. Now assume that due to some drivers mistake- he overspeed the vehicle - then speed and number of pulses received at port pin are too high. This is a real scearion failure - mal functioning issue. Now even if I reenable the Interrupt in the end of ISR, this will actually not solve my problem.

What can be possible solutions :-

1. Either I use a user variable which actually measures like how many times the Interrupt is taking place in aminute(or some time), so that if an interrupt is occuring at very high rate, then I will completely disable the interrupt.

2. Or I use some time of preemptive RTOS - or if not, then have an OS (by making it myself) above the processor level layer which actually prioritize the complate component (measuring vehicle speed is just a part of it). Something like Priority inversion can take place if some process is continously running.

This is just in thinking process. Kindly elaborate these solutiion possible. What I feel practically we have second type solution more prominent.

Thanks & Regards

Amit

-----Original Message-----
From: k...@ar.fi.lt
Sent: Thu, 16 Nov 2006 12:17:55 +0200
To: 6...
Subject: Re: [68HC12] Deferred Service Routines / Nested Interrupts Concept

Amit Gupta wrote

Edward and All

I am not clear about your answer for Query 1:-

I have an Interrupt - A ISR executing and I have cleared the interrupt at
the begining and enabled the interrupts by setting _CLI. Now assume that my
Interrupt- A occurs , then in normal situation the Interrupt will start
executing but in practical situation I dont want this to happen. What I want
is that if something like this is occuring in my system , then there is some
malfunctioning in my system , then I will lower the priority of my ISR in
compared to main finction or deffer the service routine. I am exactly not
sure about how this situation needs to be handled but there needs to
deffered the routine that is disturbing the system because in such a case
the system may execute same service routine and will cause whole system to
malfunction.

Looks like this is bit different question. Anyway they both are bit unclear.
You wrote previously that you don't want to lose interrupts, even if
interrupt A occurs while CPU is processing previous occurence of the same
interrupt A. Right? If that's the case then it's obvious that interrupt
latency is too high, your ISR A is too long to handle more offently occuring
events A. What I wrote is an idea how to not miss at least two too fast
interrupts events. "too fast" = a time gap between interrupts is shorter
than the execution time of your ISR. It's obvious that you should avoid such
situations, you should lower interrupt latency and => shorten your ISRs.
What I suggested previously was clearing interrupt flag in the beginning of
ISR. Doing it this way can shorten minimum necessary (to be handled by CPU)
pause between two A events from exe-time of long ISR A down to the time
needed for CPU to jump to ISR A and reach your interrupt_flag_clear(). Of
course it won't work if A-events are continuously coming at rate you are
unable to handle (too long interrupt latency). I suggest you to attach some
double-pulse generator to some interrupt enabled pin and play a bit with it.
ISR should have some software delay loop inside, clear interrupt flag in the
end of routine, then in the beginning. Figure the difference between min
handleable delay between pulses in both cases. Then rise frequency and see
that it won't help you always.

Now about your new question. It's again not too clear. Do you want to 1) not
lose any of interrupts and your CPU/software is too slow; or 2) you have
some interrupt enabled pin normally triggered say up to 5kHz and higher than
5kHz is unexpected and probably is the sign of hardware malfunction? Do you
want to protect from this sort of malfunction? To solve 1) you should lower
interrupt latency or even switch to faster MCU. The second can be solved
disabling interrupt A in ISR A and reenable A after min safe delay. You may
use timer interrupt to reenale A or maybe even do it in main(). In
preemptive RTOS it can be handled similarily, ISR disables itself and some
task reenables it later.

Edward

Kindly provide me with solution where we can use thread like systems or
assign priority /scheduling ? I am not sure of that

Thanks for Query 2 - I could perform nested operation using CLI

Thanks & Regards

Amit

-----Original Message-----
From: k...@ar.fi.lt
Sent: Thu, 9 Nov 2006 10:31:33 +0200
To: 6...
Subject: Re: [68HC12] Deferred Service Routines / Nested Interrupts
Concept

Amit Gupta wrote:

> Hello everyone
>
> Queries :---
>
> Query - 1
>
> While executing an "Interrupt A" Interrupt Service Routine , the
> "Interrupt A" occurs again then how should I handle the sitaution
> assuming that I dont want to miss any of the interrupts( even while
> execting ISR).
>

Clear interrupt flag at the beginning of ISR A, not at the end.
Interrupts
are lost when HW is trying to set interrupt flag that is already set. To
reduce the risk of missing interrupt, you should shorten the time
interrupt_flag_is_set. Clearing flag A in ISR A sooner, you will
definitely
shorten the time, flag A is set. This will help you in case 2 interrupt
event occur at frequency higher than ~1/Tlatency, this won't help you if
more interrupts are coming at too high rate.

> Is it related to Deferred Service Routines ??
>
> Query - 2
>
> Nested Interrupts
>
> I mean if we have two interrupts :-
> Interrupt A(higher priority) and Interrupt B(lower priority)
> Now while executing ISR of Interrupt - B, if interrupt A occurs , then
> nested interrupt will always occur or Interrupt B IST will be
completed
> first ??
>
> I tried the above example for HC08 controller - and found that ISR - B
> executes forst and then it executes ISR-A.
>

Did you CLI in ISR-B? This is how CPU works, it masks interrupts while
in
ISR. To make interrupt nesting working you should unmask interrupts in
ISR
that you want to make interruptible by higher priority interrupt.

If you mean that something unexplainable is happening if nesting, then
you
probably don't understand what can happen if you just CLI in lower
priority
interrupt. If you CLI in ISR-B and if interrupt flag-B is set, then CPU
will
interrupt your ISR-B and jump to ISR-B, and again interrupt ISR-B then
jump
to ISR-B ... To prevent it, interrupt-B should be disabled in ISR-B

ISRB()
{
disable_interrupt_B();
CLI;

ISRB_body();

reenable_interrupt_B();
}

S12/HC12 will work the same way as HC08.

S12X is bit different. In S12X, in addition to autoSEI, interrupts that
have
the same or lower priority are automatically masked by S12X interrupt
controller. In S12X interruptible ISR should look something like this

ISRB()
{
//disable_interrupt_B and all interrupts that have
// priority <= prio(B)();

// ^^ - this is done before CPU enters ISRB() by
// S12X hardware.

CLI; // - this is still necessary to enable interrupt nesting

ISRB_body();

// reenable_interrupt_B();
// ^^ - this is not necessary, it's handled by S12X hardware
}

> Does compiler provides any optimization for the same ?

What compiler and for what the same?

Edward

>
> Thanks a lot in avance
>
> Regards
>
> Amit Gupta
>



____________________________________________________________
KEEP SPYWARE OFF YOUR COMPUTER - Protect your computer with Spyware Terminator!
Visit http://www.spywareterminator.com/install and find out more! Start a New Thread

Edward and All

I am not clear about your answer for Query 1:-

I have an Interrupt - A ISR executing and I have cleared the interrupt at the begining and enabled the interrupts by setting _CLI. Now assume that my Interrupt- A occurs , then in normal situation the Interrupt will start executing but in practical situation I dont want this to happen. What I want is that if something like this is occuring in my system , then there is some malfunctioning in my system , then I will lower the priority of my ISR in compared to main finction or deffer the service routine. I am exactly not sure about how this situation needs to be handled but there needs to deffered the routine that is disturbing the system because in such a case the system may execute same service routine and will cause whole system to malfunction.

Kindly provide me with solution where we can use thread like systems or assign priority /scheduling ? I am not sure of that

Thanks for Query 2 - I could perform nested operation using CLI

Thanks & Regards

Amit

-----Original Message-----
From: k...@ar.fi.lt
Sent: Thu, 9 Nov 2006 10:31:33 +0200
To: 6...
Subject: Re: [68HC12] Deferred Service Routines / Nested Interrupts Concept
Amit Gupta wrote:

> Hello everyone
>
> Queries :---
>
> Query - 1
>
> While executing an "Interrupt A" Interrupt Service Routine , the
> "Interrupt A" occurs again then how should I handle the sitaution
> assuming that I dont want to miss any of the interrupts( even while
> execting ISR).
>

Clear interrupt flag at the beginning of ISR A, not at the end. Interrupts
are lost when HW is trying to set interrupt flag that is already set. To
reduce the risk of missing interrupt, you should shorten the time
interrupt_flag_is_set. Clearing flag A in ISR A sooner, you will definitely
shorten the time, flag A is set. This will help you in case 2 interrupt
event occur at frequency higher than ~1/Tlatency, this won't help you if
more interrupts are coming at too high rate.

> Is it related to Deferred Service Routines ??
>
> Query - 2
>
> Nested Interrupts
>
> I mean if we have two interrupts :-
> Interrupt A(higher priority) and Interrupt B(lower priority)
> Now while executing ISR of Interrupt - B, if interrupt A occurs , then
> nested interrupt will always occur or Interrupt B IST will be completed
> first ??
>
> I tried the above example for HC08 controller - and found that ISR - B
> executes forst and then it executes ISR-A.
>

Did you CLI in ISR-B? This is how CPU works, it masks interrupts while in
ISR. To make interrupt nesting working you should unmask interrupts in ISR
that you want to make interruptible by higher priority interrupt.

If you mean that something unexplainable is happening if nesting, then you
probably don't understand what can happen if you just CLI in lower priority
interrupt. If you CLI in ISR-B and if interrupt flag-B is set, then CPU will
interrupt your ISR-B and jump to ISR-B, and again interrupt ISR-B then jump
to ISR-B ... To prevent it, interrupt-B should be disabled in ISR-B

ISRB()
{
disable_interrupt_B();
CLI;

ISRB_body();

reenable_interrupt_B();
}

S12/HC12 will work the same way as HC08.

S12X is bit different. In S12X, in addition to autoSEI, interrupts that have
the same or lower priority are automatically masked by S12X interrupt
controller. In S12X interruptible ISR should look something like this

ISRB()
{
//disable_interrupt_B and all interrupts that have
// priority <= prio(B)();

// ^^ - this is done before CPU enters ISRB() by
// S12X hardware.

CLI; // - this is still necessary to enable interrupt nesting

ISRB_body();

// reenable_interrupt_B();
// ^^ - this is not necessary, it's handled by S12X hardware
}

> Does compiler provides any optimization for the same ?

What compiler and for what the same?

Edward

>
> Thanks a lot in avance
>
> Regards
>
> Amit Gupta
> Start a New Thread