Forums

LPC Timer ISR stop after breakpoint

Started by sanylcs February 25, 2009
I had been working on LPC2214 and LPC213x/4x for some time. I use
timer as internal counting quite often. I faced a weird problem which
I don't know why it happened.

I have 2 methods. Method1 and Method2. Both Timer1 declaration as
follow.
a. Method 1
#define ONE_MS_CTR 27647
void Timer1_Init(void)
{
cpu_time = 0;
g_tmr1_ctr = 0;
T1TC = 0x00; //Clear Timer Counter
T1PR = 0x00; //No prescaler
T1MCR |= (T1MCR_MR0I); //enable interrupt
T1MCR |= (T1MCR_MR0R); //reset TIMRx when interrupt
T1MR0 = ONE_MS_CTR; //interrupt every 1ms / 1us in MAT1.1
T1TCR = 0x01; //enable timer counter
}

void Timer1_ISR(void)
{
T1IR |= T1IR_MR0; //clear irq
++g_tmr1_ctr;
}

b. Method 2
#define ONE_MS_CTR 27647
void Timer1_Init(void)
{
cpu_time = 0;
g_tmr1_ctr = 0;
T1TC = 0x00; //Clear Timer Counter
T1PR = 0x00; //No prescaler
T1MCR |= (T1MCR_MR0I); //enable interrupt
T1MCR &=~ (T1MCR_MR0R); //disable reset T1MRx when interrupt
T1MR0 = ONE_MS_CTR; //interrupt every 1ms / 1us in MAT1.1
T1TCR = 0x01; //enable timer counter
}

void Timer1_ISR(void)
{
T1IR |= T1IR_MR0; //clear irq
++g_tmr1_ctr;
T1MR0 += ONE_MS_CTR;
}

The main different is the T1MR0 register. For method1, whenever
Timer interrupt occur, T1MR0 will reset to 0. But for method2, T1MR0
will not reset but it will be updated by adding ONE_MS_CTR which is
number PCLKs for 1ms.

My problem is method1 working fine during breakpoint and after
breakpoint. But for method2, after a breakpoint, Timer interrupt seem
to stop working for a couple of minutes then resume back. Anyone can
explain why is this happen?

I am using Rowley and the target MCU is 2214 and 2131.

An Engineer's Guide to the LPC2100 Series

l... napisa(a):

[...]
void Timer1_ISR(void)
{
T1IR |= T1IR_MR0; //clear irq
++g_tmr1_ctr;
T1MR0 += ONE_MS_CTR;
}

The main different is the T1MR0 register. For method1, whenever
Timer interrupt occur, T1MR0 will reset to 0. But for method2, T1MR0
will not reset but it will be updated by adding ONE_MS_CTR which is
number PCLKs for 1ms.

My problem is method1 working fine during breakpoint and after
breakpoint. But for method2, after a breakpoint, Timer interrupt seem
to stop working for a couple of minutes then resume back. Anyone can
explain why is this happen?

If you break before line:

T1MR0 += ONE_MS_CTR;

then maybe T1TC > T1MR0

and it take long time to next equal.

Albert
a...@vp.pl schrieb:
>
> l... napisa(a):
>
> [...]
> void Timer1_ISR(void)
> {
> T1IR |= T1IR_MR0; //clear irq
> ++g_tmr1_ctr;
> T1MR0 += ONE_MS_CTR;
> }
>
> The main different is the T1MR0 register. For method1, whenever
> Timer interrupt occur, T1MR0 will reset to 0. But for method2, T1MR0
> will not reset but it will be updated by adding ONE_MS_CTR which is
> number PCLKs for 1ms.
>
> My problem is method1 working fine during breakpoint and after
> breakpoint. But for method2, after a breakpoint, Timer interrupt seem
> to stop working for a couple of minutes then resume back. Anyone can
> explain why is this happen?
>
> If you break before line:
>
> T1MR0 += ONE_MS_CTR;
>
> then maybe T1TC > T1MR0
>
> and it take long time to next equal.

You got it. Isn't it obvious ? You could have checked it easily with the
debugger => no "maybe".
--
42Bastian

Note: SPAM-only account, direct mail to bs42@...

Dnia 25-02-2009, śro o godzinie 07:55 +0100, 42Bastian napisał(a):
> a...@vp.pl schrieb:

[...]

> > then maybe T1TC > T1MR0
> >
> > and it take long time to next equal.
>
> You got it. Isn't it obvious ? You could have checked it easily with the
> debugger => no "maybe".
>

Sorry my English is bad, then I write as short as passible to show idea.
T1TC after 0xFFFFFFFF is 0x0 isn't it? => "maybe" ;-)

--
Albert

--- In l..., Albert Bartoszko wrote:
>
> Dnia 25-02-2009, śro o godzinie 07:55 +0100, 42Bastian napisał(a):
> > al_bin@... schrieb:
>
> [...]
>
> > > then maybe T1TC > T1MR0
> > >
> > > and it take long time to next equal.
> >
> > You got it. Isn't it obvious ? You could have checked it easily
with the
> > debugger => no "maybe".
> >
>
> Sorry my English is bad, then I write as short as passible to show
idea.
> T1TC after 0xFFFFFFFF is 0x0 isn't it? => "maybe" ;-)
>
> --
> Albert
>

Does that mean T1TC will continue counting even during the breakpoint?
if so, will the Timer ISR been called since the T1TC still counting?

So is this because the breakpoint only stop the ARM core, but not the
peripheral, so T1TC will continue counting, but no interrupt will be
called because the ARM cores is halt?

sanylcs schrieb:

> Does that mean T1TC will continue counting even during the breakpoint?
> if so, will the Timer ISR been called since the T1TC still counting?
>
> So is this because the breakpoint only stop the ARM core, but not the
> peripheral, so T1TC will continue counting, but no interrupt will be
> called because the ARM cores is halt?

Right. On most controllers the peripherals continue while the core is
halted.
--
42Bastian

Note: SPAM-only account, direct mail to bs42@...
Albert Bartoszko schrieb:
> Dnia 25-02-2009, śro o godzinie 07:55 +0100, 42Bastian napisał(a):
>> a...@vp.pl schrieb:
>
> [...]
>
>>> then maybe T1TC > T1MR0
>>>
>>> and it take long time to next equal.
>> You got it. Isn't it obvious ? You could have checked it easily with the
>> debugger => no "maybe".
>>
>
> Sorry my English is bad, then I write as short as passible to show idea.
> T1TC after 0xFFFFFFFF is 0x0 isn't it? => "maybe" ;-)

If in continuous mode, yes => "sure" not "maybe" :-)

--
42Bastian

Note: SPAM-only account, direct mail to bs42@...

--- In l..., 42Bastian wrote:
>
> sanylcs schrieb:
>
> > Does that mean T1TC will continue counting even during the
breakpoint?
> > if so, will the Timer ISR been called since the T1TC still
counting?
> >
> > So is this because the breakpoint only stop the ARM core, but not
the
> > peripheral, so T1TC will continue counting, but no interrupt will
be
> > called because the ARM cores is halt?
>
> Right. On most controllers the peripherals continue while the core
is
> halted.
> --
> 42Bastian
>
> Note: SPAM-only account, direct mail to bs42@
>

Thank you everyone for clearing the doubt.