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.

MSP430G2553: Help to implement workaround for errata number TA12

Part Number: MSP430G2553

Hello,

My application is behaving in an odd way and there is a chance that it is related to the MCU error described on the errata of the part as TA12. I am trying to implement the workaround but it is not doing the trick. Could I please have some code example or indications on how to implement this workaround?

At the moment, I am configuring TIMER_A_MODULE the following way, where TIMERRELOAD is a whole number:
    CCTL0 = CCIE;                           // CCR0 interrupt enabled, capture mode enabled
    CCR0 = TIMERRELOAD;                     // 1ms timer 23986
    TACTL = TASSEL_2 + MC_1;        		// ACLK, up, clr TAR
TIMER_MODULE_A also calls an interrupt subroutine.
     // Timer A0 interrupt service routine
    #pragma vector=TIMER0_A0_VECTOR
    __interrupt void TIMER0_A0_ISR(void)
    {
      timertick++;                              // update the system timer tick
      freqtimertick++;                          // update the frequency timer tick
      soundtick++;                              // update the sound frequency
      pairtick++;                               // update the pairtick;
      sampletick++;                             // update the sample tick

      if (soundflg == TRUE) {
            P2OUT ^= 0x20;


        if (soundtick == soundontime) {
            soundflg = FALSE;
            SpkrOff;
        }

      }
    }//END OF TIMER0 Interrupt

As I understand, from the workaround, I have to configure the timer in capture mode before the increment of the CRRx register and then switch back to compare. I am having difficulties in how to implement this dynamically taking into account the interrupt service.
Thank you
  • Your .png doesn't seem to have attached properly.

    Try pasting your code instead, using "Insert Code, Attach files and more.." and then picking the "<>" icon. That's also easier to read than a screen capture.

    [Edit: I think I figured out what the Erratum means.]

  • Thank you for your advice. I have uploaded the code as you suggest.
  • TASSEL=2 is SMCLK, which is (normally) not "slow" per TA12. I also don't see where you're adding 1 to the CCR (also per TA12).

    Why do you believe you're encountering TA12?
  • Hello Bruce,

    I did not write this code and it is my first time working with a TI MCU. I thought that TASSEL = 2 was to setup the timer using the ACLK. Does this configuration sintax starts from 0? so TASSEL_2 is equal to setting bits 9 and 8 from the TASSELx register to 0b10?

    Also, I thought the CCR register automatically increments when an interrupt from the peripheral occurs?

    This is a frequency counter. So everytime there is a change in the input the timer starts counting until another change. (Or so I beleive it works). I will upload the interrupt subroutine too
  • Yes, TASSEL_2 is shorthand for setting the TASSEL field to 2=0b10. TASSEL_1 would be ACLK. [Ref User Guide (SLAU144J) sec. 12.3.1.]

    In Compare mode (non-CAPture), the CCRs change only when the code changes them. The counter register (TAR) increments and is compared against the CCRs.

    A frequency counter would typically be done with TACLK as the clock (TASSEL_0). In this mode, TACLK is a clock, not a gate, so each rising edge increments the counter (TAR) by 1.
  • OK I will try with the ACLK instead. Will using this mode then make the errata valid for my case?
  • I still don't see anything adding 1 to a CCR. [Edit: Removed commentary on CCR0+Up, since it was only mostly-correct and was in any case irrelevant.]

    The code you've posted so far looks fairly ordinary (except that I don't know what SpkrOff does). What behavior are you observing that leads you to think that there's an Erratum at work?

  • Out of a production batch, around 10% of the units have a strange behaviour where they get "stucked".

    I got given the code and I do not have a debugger to test where this exactly happens.

    So after having a thoroguh look for inconsistencies and comparing with previous releases where the issue does not happen, with my limited capability I did not found anything out of place except for the errata TA12, which I believed it could have been affecting this unidentified behaviour.

    Unfortunately I do not have more concise informaiton to support that the TA12 is the cause of the issue as my knowledge about the issue is poor.
  • To answer your original question: The TA12 workaround recommends that you first find a line of code (in an ISR) that looks more or less like "CCRn++;". You then bracket that line so it looks like "CCTLn|=CAP;CCRn++;CCTLn&=~CAP;". In the absence of that original line of code there's no way to do the workaround (and most likely that is not what you are encountering).

    There are different levels of "stuck". In one, the device is doing nothing perceptible at all. In another, some (presumably important) function is not operating, but other things (LED, UART, e.g.) are. There's usually a clue there.

    Some checklist items (in no particular order):
    1) Does it start operating if you Reset it? if you power cycle it?
    2) How much current does it draw when it's stuck? (Sleep vs Active mode)
    3) When you compared the code versions, what differences did you find?
    4) You said you have no debugger. Do you have any way to load new code? My first thought would be to use the Watchdog Timer (WDT),
    which needn't be very complex.
    5) It might not be code, it might instead be electrical (directly or indirectly).
  • Thanks for the thorough reply.

    Indeed the program is not incrementing this CCRn register.

    Thank you for your advice. I have contacted the client to provide me with the necessary HW to conduct this investigation. (right now I don't even have a board).

    Thanks again for your advice.

**Attention** This is a public forum