• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 80 subscribers
  • Views 383 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MSP430FR5849: Driverlib bug configuring Timer B0

Kent Rager
Prodigy 120 points
Part Number: MSP430FR5849
Other Parts Discussed in Thread: MSP430WARE

Not sure if there is a better way to report a bug with driverlib code or not.  But I've noticed the following:

In the file timer_b.c of the driverlib code, the functions such as Timer_B_initUpMode() do not clear the ID field bits of the TBxCTL register.  Consequently, if you are using the same timer for two different purposes at different times, and these two different purposes require different settings of the ID field, you don't get a proper configuration after bits in the ID field have been set and now you want them clear.

  • 0
    TI__Genius 11850 points

    Hi Kent,

    Thanks for your post. I will look into this and get back to you.

    Best regards,

    Angelo

  • 0 in reply to Angelo Zhang87
    TI__Genius 11850 points

    Hi Kent,

    The behavior that you observed is actually the intended functionality, not a bug. Setting TBCLR does not change the input divider setting, as shown below:

    In some applications, it is convenient to leave the input divider settings unchanged so that you do not need to initialize ID later. This E2E thread shows one such example:

    https://e2e.ti.com/support/microcontrollers/msp430/f/166/t/844186

    However, please feel free to modify some code in whichever way makes the most sense for your application.

    Best regards,

    Angelo

  • 0 in reply to Angelo Zhang87
    Guru 88700 points

    Speaking (uninvited) for the Original Poster:

    Timer_B_initUpMode and Timer_B_initUpDownMode don't clear the ID field ("&= ~ID__8") before or-ing into it. So if one use requests ID=1 and the next ID=2, the final result is ID=3, not ID=2. This is unrelated to TBCLR.

    Timer_B_initContinuousMode does it correctly:

        HWREG16(baseAddress +
        OFS_TBxCTL) &= ~(TIMER_B_CLOCKSOURCE_INVERTED_EXTERNAL_TXCLK +
                         TIMER_B_UPDOWN_MODE +
                         TIMER_B_DO_CLEAR +
                         TIMER_B_TBIE_INTERRUPT_ENABLE +
                         CNTL_3 +
                         ID__8
                         );

    [Edit: Small clarification.]

  • 0 in reply to Bruce McKenney47378
    Prodigy 120 points

    Yes, this is exactly what I was trying to report.  In the case of my application, I'm using timer B0 for two different purposes at different times.  The timer is configured as such:

    1st case:

    Timer_B_initUpModeParam upParam = {
    .clockSource = TIMER_B_CLOCKSOURCE_SMCLK,
    .clockSourceDivider = TIMER_B_CLOCKSOURCE_DIVIDER_1,
    .timerPeriod = 124,
    .timerInterruptEnable_TBIE = TIMER_B_TBIE_INTERRUPT_DISABLE,
    .captureCompareInterruptEnable_CCR0_CCIE = 0,
    .timerClear = TIMER_B_DO_CLEAR,
    .startTimer = true
    };
    Timer_B_initUpMode(TIMER_B0_BASE, &upParam);

    and the 2nd case:

    Timer_B_initUpModeParam upParam = {
    .clockSource = TIMER_B_CLOCKSOURCE_SMCLK,
    .clockSourceDivider = TIMER_B_CLOCKSOURCE_DIVIDER_64,
    .timerPeriod = 0,
    .timerInterruptEnable_TBIE = TIMER_B_TBIE_INTERRUPT_DISABLE,
    .captureCompareInterruptEnable_CCR0_CCIE = 0,
    .timerClear = TIMER_B_DO_CLEAR,
    .startTimer = true
    };
    Timer_B_initUpMode(TIMER_B0_BASE, &upParam);

    The first case of calling Timer_B_initUpMode() does a logical OR of 00b into the ID field of register TBxCTL.  The second case of calling Timer_B_initUpMode() does a logical OR of 11b into the ID field.  When I then go back to the first case, it ORs 00b into the ID field without first clearing the ID field, so the ID field remains 11b.

  • 0 in reply to Kent Rager
    TI__Genius 11850 points

    Hi Kent and Bruce,

    Thank you both for clarifying! I understand the concern now and have reported this to the appropriate team members within TI.

    Best regards,

    Angelo

  • 0 in reply to Angelo Zhang87
    TI__Intellectual 1175 points

    Hi Kent and Bruce:

    You would be correct. Thank you for pointing this out. Please make the appropriate changes in your local version, we will add your fix in the next MSP430Ware release.

    Thanks,

    Wallace

**Attention** This is a public forum