Stumped by MSP430F2013 timer - broken?!

Thanks to Tim et al, I've got the CCR working... but the timer itself
doesn't function correctly. Is there a known issue with the timer in
this part not actually working? I can't get it to count past
approximately 0x7FE0 (and I've tried two chips, one DIP, one TSSOP).

Very simple init code:

int main(void) {
BCSCTL1 = CALBC1_1MHZ;
DCOCTL = CALDCO_1MHZ;

P1SEL=0x04;
P1DIR=0x05;

TACCTL1=OUTMOD_A4;
TACCR0=0xFFFF;
TACCR1=0x1000;
TACTL=TASSEL_2 | ID_0 | MC_2 | TAIE | TACLR;

_EINT();

while(1) {
if (TAR & 0x8000u)
P1OUT |=1;
else
P1OUT &=~1;
}
}

On P1.2 I see a _32ms_ period square wave, indicating that the timer is
only counting about 32K counts.
P1OUT never changes state.

If I change the if statement to if (TAR & 0x4000u) I see a square wave
on P1OUT. So the timer is running, and the capture/compare is working
as expected.

I tried changing from continuous mode (MC_2) to up mode (MC_1), and
tinkering with TACCTL0. It works as expected while TACCTL0 <= ~0x8000.
After that point, increasing TACCTL0 doesn't increase the period of the
timer!

Single-stepping shows that TAR resets to 0 somewhere between 0x7FE0 and
0x8000.

The overflow interrupt obviously never fires. The capture/compare
interrupt can be made to fire, though.

Any ideas? I actually asked TI for a "please explain" on this one...
it's bizarre!

larwe wrote:
> Thanks to Tim et al, I've got the CCR working... but the timer itself
> doesn't function correctly. Is there a known issue with the timer in

I got home and one of my dogs started to go through my laptop bag... at
which point I realized that my problem is the WDT.

Oops, thanks folks - please come again.

Hello Lewin,

> 
>>Thanks to Tim et al, I've got the CCR working... but the timer itself
>>doesn't function correctly. Is there a known issue with the timer in
> 
> I got home and one of my dogs started to go through my laptop bag... at
> which point I realized that my problem is the WDT.
> 
> Oops, thanks folks - please come again.
> 

Give you dog an extra cookie for his/her consulting effort ;-)

Most of those kinds of problems seem to either be caused by the WDT 
(like our dogs, it turns grumpy when meal service doesn't happen 
promptly enough) or by ports set to the wrong mode or the mode setting 
being accidentally trampled upon by a foreign routine that was left in 
the code.

-- 
Regards, Joerg

http://www.analogconsultants.com