MSP430FR6879: TimerA0 CCIFG interrupt

Hi Koki,

(1) Captures can be initiated by software. It can be found in page 651 in User's Guide.

(2) There is a sample code in resource explorer: MSP430FR69xx_ta0_capture.c. It may help you.

Regards,

Yuhao

Hi, Yuhao

Yuhao Zhao said:

(1) Captures can be initiated by software. It can be found in page 651 in User's Guide.

Yes, thank you for the reference information.

I read that passage, but I didn't know if it had anything to do with my problem.

The current problem is that an unexpected interrupt may occur immediately after timer A0 start.

Is there any operation that triggers CCIFG due to access to the peripheral, such as a setting error in timer A?

Thanks,

Koki

a) The capture trigger (CCIFG) happens independently of whether the timer is running (MC>0). It's usually prudent to clear CCIFG after a "long" idle time since an event could have happened eons (or at least milliseconds) in the past.

b) A capture can happen independently of activity on the pin, in the case where the capture input (CM+CCIS) is changed when CAP=1. This is the essence of the "NOTE" in UG (SLAU367P) Sec 25.2.4.1.  This is used intentionally in "Capture Initiated by Software" [Sec 25.2.4.1.1].

c) SCS will only trigger a capture event after the next tick of the SSEL (ACLK in this case), which means it may remember the event  for some time.

As a practical matter, I suggest you write TA0CCTL1=0 when you stop the timer, to make sure it doesn't later tell you about (stale) history.

Hi, Bruce

Thanks for the useful information. The following are supplements and questions regarding a) to c).

Bruce McKenney said:

a) The capture trigger (CCIFG) happens independently of whether the timer is running (MC>0). It's usually prudent to clear CCIFG after a "long" idle time since an event could have happened eons (or at least milliseconds) in the past.

I thought CCIFG was a flag that was set after the timer started running. Does that mean it may be set even before the timer starts? Please tell us in detail about the above and how to deal with it.

Bruce McKenney said:

b) A capture can happen independently of activity on the pin, in the case where the capture input (CM+CCIS) is changed when CAP=1. This is the essence of the "NOTE" in UG (SLAU367P) Sec 25.2.4.1.  This is used intentionally in "Capture Initiated by Software" [Sec 25.2.4.1.1].

At initialization, TA0 is set in the following order.

- TA0CCTL1 = 0xC910

- TA0CTL = 0x0120

According to this order, "capture input select" and "capture enable" are performed at the same time (TA0CCTL1 register setting). Does the above setting order still apply to "NOTE: Changing Capture Inputs" in the User Guide? If applicable, please tell me how to deal with it.

Bruce McKenney said:

c) SCS will only trigger a capture event after the next tick of the SSEL (ACLK in this case), which means it may remember the event  for some time.

As a practical matter, I suggest you write TA0CCTL1=0 when you stop the timer, to make sure it doesn't later tell you about (stale) history.

Actually, when the timer is stopped, the following operations are performed.

- TA0CTL = 0x0000

- TA0CCTL1 & = 0xFFFE (CCIFG clear)

Thanks,

Koki

a) CCIFG indicates an event; which event depends on the CAP setting. If the SSEL clock isn't active (with CAP=1) the behavior is roughly equivalent to a pin interrupt, though SCS will interfere. I don't think the UG says this explicitly (perhaps by omission).

b) I'm not sure the UG says explicitly. Observed behavior is that source transitions simultaneous with CAP=0->1 do not generate a CCIFG. One expects that the capture input ("pin") state at that moment is instead saved as the initial condition, since I don't know when else it would happen.

c) Yes, you mentioned that you're leaving CAP on all the time. I was suggesting you could avoid glitches (a-c) if you clear it when you're not interested in it. I've seen SCS pend a pin event for a fairly long time (slow/intermittent TACLK).

[To save everyone a trip through the UG:

- TA0CCTL1 = 0xC910

- TA0CTL = 0x0120

is

- TA0CCTL1 =  CM_3 | CCIS_0 |  SCS | CAP |  CCIE | (0*CCIFG); // Both edges, CCI1A, Sync, CAP, enable

- TA0CTL =  TASSEL_1 |  ID_0 | MC_2 | (0*TACLR) | (0*TAIFG); // ACLK/1, Continuous, no clear

]

Hi, Bruce

Thanks for the detailed information. In summary, changing the input signal with TA0 enabled can lead to unexpected events. Also, if you select the input signal and enable the timer at the same time, you probably won't get any unexpected events.

Based on the above, I would like to ask you one question. My current operation is to select the input signal and enable the timer at the same time. However, in rare cases, interrupt processing may be performed immediately after the timer A0 starts, regardless of the input pin. If you know the cause, please let me know.

Bruce McKenney said:

I was suggesting you could avoid glitches (a-c) if you clear it when you're not interested in it. I've seen SCS pend a pin event for a fairly long time (slow/intermittent TACLK).

In fact, I don't really understand the above sentence.

Thanks,

Koki

What I suspect is happening: You stop the capture but pin transitions continue on the capture pin. Your "stop" operation sets MC=0 (Stop counting) and SSEL=0 (TACLK, which probably isn't ticking) but leaves CAP=1 and SCS=1. Since CAP=1, the next pin transition is registered by the timer, but since SCS=1 this won't be presented (CCIFG) since TACLK isn't ticking. When you (perhaps. much) later set SSEL=1 (ACLK) that clock ticks and then the stale pin transition is presented as a CCIFG.

If you were to set SCS=0, the pin transition would be presented (CCIFG) immediately. I suspect this still isn't what you want, but it would be more evident what is happening.

It seems to me that you aren't interested in any pin transitions between the times you "stop" /"start" your capture. If so, you should set CAP=0 during that time so the timer (capture unit) isn't watching. Concretely, replace:

> TA0CCTL1 & = 0xFFFE // CCIFG=0

with

> TA0CCTL1 = 0;    // CAP=0, SCS=0, CCIE=0, CCIFG=0

Hi, Bruce

After setting TA0CCTL1 at the start of operation, it only writes 0 to the CCIFG flag and does not switch the capture input (CCIS).

Is it correct to recognize that it is necessary to access TAxCCTLn with CM = 0 / CAP = 0 even when manipulating other bits?

Thanks,

Koki

1) you mentioned that you start capture using:

- TA0CCTL1 = 0xC910

which will un-do the setting-to-0. Since just before that, CAP=0, changing CCIS/CM simultaneous with setting CAP=1 will not generate a CCIFG  (rather the timer will record the initial conditions).

2) If CAP=1 (already) and then you change CCIS+CM it can generate a CCIFG. Clearing SCS=1->0 might also in some circumstances.

Hi, Bruce

Bruce McKenney said:

which will un-do the setting-to-0. Since just before that, CAP=0, changing CCIS/CM simultaneous with setting CAP=1 will not generate a CCIFG  (rather the timer will record the initial conditions).

I also think that CCIFG will not be generated because CCIS / CM and CAP = 1 are set at the same time.

--TA0CCTL1 = 0xC910

Bruce McKenney said:

2) If CAP=1 (already) and then you change CCIS+CM it can generate a CCIFG. Clearing SCS=1->0 might also in some circumstances.

The operation of register change when CAP = 1 is described below.

--TA0CCTL1 & = 0xFFFE // CCIFG = 0

Register changes only clear CCIFG, no CCIS, CM or SCS changes. Therefore, I do not understand the reason why CCIFG is set regardless of the fluctuation of the input signal after starting timer A0.

Please let me know if you need additional information to resolve the issue.

Thanks,

Koki

The additional information I would want would be a scope trace of your input signal (P1.6) prior to a failing case, with markers showing (a) when the "stop" was performed and (b) when the subsequent "start" was performed.

I anticipate that we will see one or more transitions (edges) in the signal between the two markers. If so, that would produce the symptom you described.

Hi, Bruce

When we verified the operation with the contents of the proposal, we were able to confirm that no unintended interrupts were received. Thank you very much. Could you elaborate on the need to set TAxCCTLn = 0 when stopped? I looked back at past exchanges, but I couldn't fully understand the cause of this phenomenon.

Thanks,

Koki

I think I explained the entire sequence of "What I suspect is happening" above. It's a consequence of observations (a)+(c) in reply #3.

Strictly speaking, you probably only have to clear CAP+SCS when you "stop", but I've never tried it that way and there may be something I'm forgetting.

Hi, Bruce

As you answered, the input signal is inverted after the capture is stopped, so I think it matches the situation that occurs.

Even if the input signal is inverted, an unintended interrupt may or may not occur. Does this match what you answered? (In many cases, interrupts do not occur when I confirm.)

Thanks,

Within the bounds of the experiment, I would expect it to happen every time there's a transition during "stop" mode, since it's the (perhaps non-obvious) result of features described in the User Guide.

One possibility for an illusion: Since you're using ACLK when active, the "surprise" CCIFG that happens at the first tick could be up to about 31 usec after the re-start.

Hi, Bruce

Bruce McKenney said:

result of features described in the User Guide.

Is the description of UG you are talking about the following NOTE? I thought this NOTE contained the nuance that "may cause" does not always occur.

Bruce McKenney said:

31 usec after the re-start.

Whenｆ_ACLK is 32768 Hz, is 31us calculated from 1 /ｆ_ACLK ?

Bruce McKenney said:

One possibility for an illusion: Since you're using ACLK when active, the "surprise" CCIFG that happens at the first tick could be up to about 31 usec after the re-start.

It takes 31usec after restarting, so it is possible that the capture operation has started again before the CCIFG setting is reflected, right?

Thanks,

Hi, Bruce

Bruce McKenney said:

One possibility for an illusion: Since you're using ACLK when active, the "surprise" CCIFG that happens at the first tick could be up to about 31 usec after the re-start.

Is it okay to interpret it as the behavior of losing interrupt request?

We have confirmed that CCIFG may not be set even if the capture signal transition does not occur after restarting.

Thanks,

I don't know of a mechanism which would cause losing the trigger event while CAP=1, and I'm not in a position to replicate your experiment. I defer to your observations.

I think you now know as much as I do about this phenomenon, and can judge whether to adopt my suggested remedy or to come up with something different.