MSP430 TA12 bug workaround code example??

bowerymarc said:

First, it's not clear whether, once this error condition happens, it's just for one interrupt or maybe no interrupts happen forever after?

I think you misunderstood the problem.

The erratum applies if, say TAR is 10, CCR0 is 10 and you increment CCR0 to 11. Then the interrupt when TAR eventually increments to 11 may be lost (because TAR was already between 10 and 11) and the next interrupt occurs when TAR counts to 11 once more (after 65536 more ticks, if in cont mode, less in up mode).

If TAR is 9 when you increment CCR0 from 10 to 11, this erratum does not apply. It's not clear whether this erratum applies only if you increment CCRx by 1 (giving you oen interrupt on every tiemr tick) or when you increment it to TAR+1 (e.g. every 10th tierm tick, bu tyou spent the last 9 since last itnerupt in othe rISRs or with iotnerupt disabled, and alre late with your ISR execution).

However, the suggested workaround is to set the CAP bit before incrementing CCRx and then clear it again.

yes I believe you're right, it only applies to incrementing CCRx.  If CCRx is not changing then no problem.

it would be nice to have a clarification, but i suspect it would be setting CCRx to TAR+1 within a particular time window (for example what if that is done outside of the ISR?)

Still, I did ask for code example for the workaround.  IMHO TI should supply actual code for any of these workarounds to avoid confusion.

bowerymarc said:

but i suspect it would be setting CCRx to TAR+1 within a particular time window (for example what if that is done outside of the ISR?)

I don't think it makes a difference whether you do it in an ISR or outside (e.g. busy-waiting for CCIFG being set). If the timer clock is derived from teh same source as MCLK, there are only a few MCLK cycles per timer tick (depending on dividers) and it is unlikely that you do a CCRx=TAR+1 (or CCRx++) action and expect to have it finished before TAR increments to the new trigger. Also, time rincrement and timer register access are synchronous. However, if the timer is clocked by a different source, you don't know where in the counting (and compare) cycle you are. Goinfg out and back into compare mode synchronizes this as if there would be oen or more additional timer ticks between the change and the next interrupt trigger.

bowerymarc said:

Still, I did ask for code example for the workaround.

Well, how much sample code do you need for setting and clearing a bit in a register?

bowerymarc said:

TI should supply actual code for any of these workarounds to avoid confusion.

I agree that sometimes sample code would be nice. However, sample code in a device/errata sheet (or users guide) is assembly only, as assembly instruction sis the only thing that is documented for the hardware. Sure, there are C compilers (eveon from TI), but nobody can guarantee that every C compiler will produce the proper code for the workaround (even though this is normally the case).
Would ASM sample code help you? Here it comes (for CCR0):

BIS #CAP, &TA0CCTL0
ADD #1, &TA0CCR0
BIC #CAP, &TA0CCTL0