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.

LP-MSPM0G3507: Timer

Part Number: LP-MSPM0G3507
Other Parts Discussed in Thread: MSPM0G3507

Tool/software:

I'm using the sysctl_lfxt_standby_LP_MSPM0G3507_nortos_ticlang project from the mspm0_sdk_2_04_00_06 SDK.

The only change I made in syscfg is setting the Timer Clock Prescaler from 129 to 1.

Based on the code I'm using, one cycle should be 100 ms. However, I'm noticing a 122 µs difference between debug and non-debug modes — it’s 100.143 ms while debugging and 100.265 ms when running normally. So why is there a 122 µs difference?

 #include "ti_msp_dl_config.h"


 #define TIMER_75_MILLISECONDS_TICKS (2458)
 #define TIMER_25_MILLISECONDS_TICKS (820)
 
 int main(void)
 {
     SYSCFG_DL_init();
 
     NVIC_EnableIRQ(TIMER_0_INST_INT_IRQN);
     DL_SYSCTL_enableSleepOnExit();
 
     DL_TimerG_startCounter(TIMER_0_INST);
 
     while (1) {
         __WFI();
     }
 }
 
 void TIMER_0_INST_IRQHandler(void)
 {
     static uint32_t count = TIMER_75_MILLISECONDS_TICKS;
     switch (DL_TimerG_getPendingInterrupt(TIMER_0_INST)) {
         case DL_TIMER_IIDX_ZERO
                 DL_TimerG_stopCounter(TIMER_0_INST);
 
                 if (count > TIMER_25_MILLISECONDS_TICKS) {
                     count = TIMER_25_MILLISECONDS_TICKS;
                 } else {
                     count = TIMER_75_MILLISECONDS_TICKS;
                 }
 
                 DL_Timer_setLoadValue(TIMER_0_INST, count);
             
                 DL_TimerG_startCounter(TIMER_0_INST);
 
             DL_GPIO_togglePins(GPIO_LEDS_PORT,
                 (GPIO_LEDS_USER_LED_1_PIN));
             break;
         default:
             break;
     }
 }

  • SWD access the bus has some impact to system, please try to run MSPM0 without debug or freerun mode in Debug mode[Run - Free Run]

  • This 122 µs difference only occurs when entering low-power (standby) mode. Without low power, the timing is always 100.143 ms. So, can I say the 122 µs is the wake-up time from standby to run mode?

  • Additional Note: When I read the counter value inside the ISR, it shows 819 or 2457 (based on the last programmed value) instead of 0. This suggests that 2 cycles have already elapsed by the time ISR runs.

  • 7.8 Timing Characteristics in Datasheet shows the wakeup time.

    This suggests that 2 cycles have already elapsed by the time ISR runs.

    ISR entering to ISR's first code need at least 30+ CPU cycles.

    This 122 µs difference only occurs when entering low-power (standby) mode. Without low power, the timing is always 100.143 ms. So, can I say the 122 µs is the wake-up time from standby to run mode?

    IT means you measure the time interval between timer starting running and ISR first line of code? There is too much software influence between this time interval.

    For the timer debug, better to use PWM with waveform output to run some hardware debug