1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

Stumped by MSP430F2013 timer - broken?!

Discussion in 'Embedded' started by larwe, Oct 13, 2006.

  1. larwe

    larwe Guest

    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, Oct 13, 2006
    #1
    1. Advertisements

  2. larwe

    larwe Guest

    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.
     
    larwe, Oct 14, 2006
    #2
    1. Advertisements

  3. larwe

    Joerg Guest

    Hello Lewin,
    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.
     
    Joerg, Oct 14, 2006
    #3
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.