interrupt overhead in EVB mode (9S12DP256)

Started by ctrobot28 August 27, 2003
My little program runs from ram, the board is in EVB mode (dbug12 in
flash). It uses RTI interrupts, approx. as follows:

volatile int foo = 0;

rti_interrupt_handler() { foo = 100; }

test_func() {
enable_rti_interrupts();
while (foo == 0); // spin
// continue
}

The interrupts happen, the handler runs, but the program never gets
past the spin loop. The frequency divisor (RTICTL) is set to 10X2^16,
and osc_clock is 4000000, so (if I'm understanding this stuff right)
there should be an interrupt about every .16 seconds, i.e. pretty low
frequency. My only guess is that dbug12 is adding some _huge_
overhead to interrupt handling, so that even though my handler is
extremely short, by the time it finishes there's another interrupt
pending. Anyone know is this is plausible? Is there some known
problem with using interrupts in EVB mode?

Patrick



I used D-BUg to develop codes and no, D-BUG does not put huge
overhead.

I am not much good at C but where is 'foo' decremented. Is it
automatically being decremented somewhere else? --- In , "ctrobot28" <pdm@o...> wrote:
> My little program runs from ram, the board is in EVB mode (dbug12
in
> flash). It uses RTI interrupts, approx. as follows:
>
> volatile int foo = 0;
>
> rti_interrupt_handler() { foo = 100; }
>
> test_func() {
> enable_rti_interrupts();
> while (foo == 0); // spin
> // continue
> }
>
> The interrupts happen, the handler runs, but the program never gets
> past the spin loop. The frequency divisor (RTICTL) is set to
10X2^16,
> and osc_clock is 4000000, so (if I'm understanding this stuff
right)
> there should be an interrupt about every .16 seconds, i.e. pretty
low
> frequency. My only guess is that dbug12 is adding some _huge_
> overhead to interrupt handling, so that even though my handler is
> extremely short, by the time it finishes there's another interrupt
> pending. Anyone know is this is plausible? Is there some known
> problem with using interrupts in EVB mode?
>
> Patrick





I see where you are changing the value of 'foo' to get out of the
loop, but I don't see in the interrupt handler where you clear RTIF.
According to the book, you need to clear RTIF by writing to the
real-time interrupt flag register (RTIFLG) with RTIF (bit 7) set.
Otherwise you have a constant flag that triggers the interrupt; as
soon as you leave the interrupt handler it is immediately called
again because of the flag.

Hope this helps.

-- DW --- In , "zeta_alpha2002"
<zeta_alpha2002@y...> wrote:
> I used D-BUg to develop codes and no, D-BUG does not put
huge
> overhead.
>
> I am not much good at C but where is 'foo' decremented. Is it
> automatically being decremented somewhere else? > --- In , "ctrobot28" <pdm@o...>
wrote:
> > My little program runs from ram, the board is in EVB mode
(dbug12
> in
> > flash). It uses RTI interrupts, approx. as follows:
> >
> > volatile int foo = 0;
> >
> > rti_interrupt_handler() { foo = 100; }
> >
> > test_func() {
> > enable_rti_interrupts();
> > while (foo == 0); // spin
> > // continue
> > }
> >
> > The interrupts happen, the handler runs, but the program
never gets
> > past the spin loop. The frequency divisor (RTICTL) is set to
> 10X2^16,
> > and osc_clock is 4000000, so (if I'm understanding this stuff
> right)
> > there should be an interrupt about every .16 seconds, i.e.
pretty
> low
> > frequency. My only guess is that dbug12 is adding some
_huge_
> > overhead to interrupt handling, so that even though my
handler is
> > extremely short, by the time it finishes there's another
interrupt
> > pending. Anyone know is this is plausible? Is there some
known
> > problem with using interrupts in EVB mode?
> >
> > Patrick






I didn't know I needed to clear that flag - that must be what's
happening! Thank you!

--- In , "dw4guitar" <dickwebb@i...> wrote:
> I see where you are changing the value of 'foo' to get out of the
> loop, but I don't see in the interrupt handler where you clear
RTIF.
> According to the book, you need to clear RTIF by writing to the
> real-time interrupt flag register (RTIFLG) with RTIF (bit 7) set.
> Otherwise you have a constant flag that triggers the interrupt; as
> soon as you leave the interrupt handler it is immediately called
> again because of the flag.
>
> Hope this helps.
>
> -- DW
>