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.

MSP430F5438A: Timer A some times get stuck

Part Number: MSP430F5438A

Hi

I have a custom board where some of the 5438A Rev F MCUs Timer A TA0R some times (It works just fine maybe 99 times out of 100 Timer A starts) never starts and when I halt the CPU MC is MC_2 and TASSEL is TASSEL_1 (ACLK).


volatile unsigned char g_bWaitForDelay = 0;

#pragma vector=TIMER0_A0_VECTOR
__interrupt void TIMERA0_A0_ISR(void)
{
  g_bWaitForDelay = 0;
  __low_power_mode_off_on_exit();
}

Before starting Timer A I have verified that it isn't running (i.e. MC == 0)

unsigned short delay = 0x140; //LPM for 10 ms with ACLK at 32kHz
g_bWaitForDelay = 1;
Timer_A_clearCaptureCompareInterrupt(TIMER_A0_BASE, TIMER_A_CAPTURECOMPARE_REGISTER_0);
Timer_A_enableCaptureCompareInterrupt(TIMER_A0_BASE, TIMER_A_CAPTURECOMPARE_REGISTER_0);
Timer_A_setCompareValue(TIMER_A0_BASE, TIMER_A_CAPTURECOMPARE_REGISTER_0, delay);
Timer_A_initContinuousModeParam param;
param.clockSource = TIMER_A_CLOCKSOURCE_ACLK;
param.clockSourceDivider = TIMER_A_CLOCKSOURCE_DIVIDER_1;
param.startTimer = true;
param.timerClear = TIMER_A_DO_CLEAR;
param.timerInterruptEnable_TAIE = TIMER_A_TAIE_INTERRUPT_DISABLE;
Timer_A_initContinuousMode(TIMER_A0_BASE, &param);

At this point I do a 

while(g_bWaitForDelay)
{
  __bis_SR_register( LPM0_bits + GIE );
}

To save power during the wait.

At this point my application some times get stuck since TA0R is stuck at 0x0000 and I'm waiting for the interrupt at TA0CCR0. (I have at this point tried to get the TA0R to run again by using the debugger and switching MC to MC_0, resume execution, and then put it back to MC_2 but TA0R is still stuck at 0x0000)
I'm just showing the code related to Timer A (Unfortunately I have not been able create a small sample project that gives the same problem so there might be something else causing this that I don’t understand).
Note that this only happens on some of the boards with 5438A’s.

What am I doing wrong on the failing 5438A’s?

  • Hello Jompa,

    I find it very strange that it's only happening on some custom boards with the MSP430F5438A but not others. Perhaps, this is an errata that hasn't been taken into account and is varying across different devices. I looked at the erratasheet and found errata TAB23, which happens when a timer in Up mode is stopped and the counter register (TAxR/TBxR) is equal to the TAxCCR0/TBxCCR0 value, a read of the TAR/TBR register may return an unexpected result.

    If you haven't done it already, take a look at the F5438A code examples for Timer_A inside Resource Explorer in CCS.

    Regards,

    James

    MSP Customer Applications
  • What's driving ACLK? Is it REFOCLK, or are you using a 32kHz crystal (XT1)?
  • TAB23 is about Up mode and I'm using 10b = Continuous mode and I'm not reading TAxR so I don't think the TAB23 errata is applicable
  • I'm using XT1 when this problem occures.
  • I think I have found a workaround

    After calling
    Timer_A_initContinuousMode(TIMER_A0_BASE, &param); //This should be all that is needed to start TA0R but for some unknown reason it seems that it some times isn't

    I do the following

    TA0CTL &= ~TASSEL_3; //Clear clock source to TAxCLK just to switch to another souce (I have choosen a souce that isn't running in my case)
    TA0CTL |= TIMER_A_CLOCKSOURCE_ACLK; //Set clock source to the wanted one again

    This seems to always start TA0R as wanted. I need to do some further testing to see that this really is a working.


    Furter information regarding ACLK:
    When the problem occures my settings are.
    UCSCTL4
    SELA is 000 (XT1CLK)

    UCSCTL8
    ACLKREQEN is 1 (ACLK conditional requests are enabled)

    UCSCTL7
    XT1LFOFFG is 0 (No fault condition occurred after the last reset)
    UCSCTL6
    XTS is 0 (Low-frequency mode)
    XT1BYPASS is 0 (XT1 sourced from external crystal)

    and my RTC is running from ACLK without any problems.

**Attention** This is a public forum