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.

CCS/MSP432P401R: Doubts about Timer A examples

Part Number: MSP432P401R

Tool/software: Code Composer Studio

Hello!

I am having a few problems in understanding Timer_A functionalities. I've already read the technical reference manual, but I can't understand the examples from resource explorer/driverlib.

For me, the example is a bit confusing. In the comment section, it says that the TACLK will use the 1.045MHz SMCLK. Then, it says TACLK = SMCLK = 3MHz.

As far as I understand, the clock being trully in the firmware is TACLK = 3MHz, since the divider is 1, right? And if this is the correct case, I don't understand how TIMER_PERIOD = 127 generates ~233 us, as stated in the comments.

My calculations (might be wrong): 3MHz / 127 = 23622 Hz = 42.3 us.

Am I missing something?

Thanks a lot for your help!

The partial code taken from resource explorer > timer_a_updown_compare_multiple_pwm, with the initial comments is the following:

/*******************************************************************************

 * MSP432 PWM TA1.1-2, Up/Down Mode, DCO SMCLK
 *
 * Description: This program generates two PWM outputs on P2.2,3 using
 * Timer1_A configured for up/down mode. The value in CCR0, 128, defines the
 * PWM period/2 and the values in CCR1 and CCR2 the PWM duty cycles. Using
 * ~1.045MHz SMCLK as TACLK, the timer period is ~233us with a 75% duty cycle
 * on P7.7 and 25% on P7.6.
 * SMCLK = MCLK = TACLK = default DCO 3MHz
 * Author: Timothy Logan
*******************************************************************************/
/* DriverLib Includes */
#include <ti/devices/msp432p4xx/driverlib/driverlib.h>

/* Application Defines */
#define TIMER_PERIOD 127
#define DUTY_CYCLE1 32
#define DUTY_CYCLE2 96

/* Timer_A UpDown Configuration Parameter */
const Timer_A_UpDownModeConfig upDownConfig =
{
        TIMER_A_CLOCKSOURCE_SMCLK,              // SMCLK Clock SOurce
        TIMER_A_CLOCKSOURCE_DIVIDER_1,          // SMCLK/1 = 3MHz
        TIMER_PERIOD,                           // 127 tick period
        TIMER_A_TAIE_INTERRUPT_DISABLE,         // Disable Timer interrupt
        TIMER_A_CCIE_CCR0_INTERRUPT_DISABLE,    // Disable CCR0 interrupt
        TIMER_A_DO_CLEAR                        // Clear value

};

  • Daniel,

    I also think this is a mistake in the comments.

    The SMCLK runs at 3 MHz by default and is the timer a source with no divider in this example.

    Since this is UP/DOWN configuration, your calculation is half-right. Literally.  The 128 ticks from 0 to 127 is only half of the period.  So you would really have a period that is double what you have calculate (and frequency cut in half).  Other than that, your equations look right.  Reference figure 17-9 in the TRM.

    I verified the 12 kHz and 84 uS frequency/period on oscilloscope for sanity check.

    Thank you for the feedback.  I have suggested these changes to the author. ( I will reply again if the author says the 1.045 MHz is actually intended, but my guess is this comment was by mistake.)

    Do you have further questions regarding this?

  • John P. Morrison said:

    Daniel,

    I also think this is a mistake in the comments.

    The SMCLK runs at 3 MHz by default and is the timer a source with no divider in this example.

    Since this is UP/DOWN configuration, your calculation is half-right. Literally.  The 128 ticks from 0 to 127 is only half of the period.  So you would really have a period that is double what you have calculate (and frequency cut in half).  Other than that, your equations look right.  Reference figure 17-9 in the TRM.

    I verified the 12 kHz and 84 uS frequency/period on oscilloscope for sanity check.

    Thank you for the feedback.  I have suggested these changes to the author. ( I will reply again if the author says the 1.045 MHz is actually intended, but my guess is this comment was by mistake.)

    Do you have further questions regarding this?



    Hello, John!

    Thank you for your answer, this issue was driving me crazy. Your explanation helped me a lot in understanding this.

    I got my PWM working now, with the intended frequency.

    No more questions!

    Thank you again.

  • Hey, glad I could assist!

    It was confirmed to be a typo in the comments and should be fixed in future releases.

    Thanks for spotting this and for your feedback.

**Attention** This is a public forum