MSP430FR5989-EP: Loss of Timer B Interrupt Flag

That errata requires three things to line up to create the error: 1) a read/modify/write operation on the IFG register, 2) DMA occurring at that time, 3) an incoming interrupt. An extremely unlikely set of conditions. So I expect the problem is elsewhere.

Looking back at your earlier message, I see no particular reason to use a timer. Or at least not in that way. But this reminds me that once upon a time, one way to get an accurate DCO clock frequency was to count SMCLK cycles using a timer based on an accurate ACLK. I did that but used two timers. One running from SMCLK and another from ACLK. The SMCLK timer was in UP mode doing other things so its ISR incremented a counter. The ACLK ISR handled the other details about once a second.

Oh, reading TB0R is a problem because ACLK isn't synchronous with MCLK. "When the timer clock is asynchronous to the CPU clock, any read from TBxR should occur while the timer is not operating or the results may be unpredictable."

Hi David,

Thanks for your reply.

The conditions that you described are not the same as the ones described in the errata sheet. In particular, condition number 3 (incoming interrupt) is not present in the DMA7 description.
I have the following questions regarding this new condition:
1) Does this interrupt need to be from the same module as the IFG register? Or, can it be another module (e.g., SPI) that triggers an interrupt while a RMW of an IFG register is taking place (e.g., TimerB)?
2) When you say incoming interrupt, does that mean that both GIE and the module IE need to be set? Or, is an IFG set sufficient (with GIE and module IE OFF)?

We suspect that the issue that we encountered is due to DMA7 because the issue has rarely happened and the only reasonable explanation is an errata or an electronic issue where the ACLK glitches and increments the counter several times, making the flag to be set to true before setting it to false.

Regarding your comments on the TB0R reading, what you say does not apply because in the actual implementation we read TB0R until two consecutive readings return the same value. In this way, if we read TB0R while it´s changing we would not consider it correct and would read TB0R again.

Let me know if you need more information.

From errata: "a newly arriving interrupt from the same module can get lost". So there is a problem when the CPU is altering the IFG register, gets paused by a DMA operation, and a new interrupt arrives. The errata doesn't say it has to be the same one the CPU is changing.

There is a DMA setting that tells it not to pause read-modify-write operations which would seem to be the cure for this but it isn't mentioned in the errata.

All interrupts begin with the IFG. What happens after that depends on the enables. This errata speaks only to the IFG. Or at least that is the way I read it.

It sure is nice that you use code different (TB0R) from what you posted here.

Hi Tomas,

I don't know much about this errata, according to workaround1, you can read TAxIV to check whether the IFG is set, so it will not trigger the same confition with DMA7. Does it help on the issue?

Meanwhile, in previous e2e thread, you describe that: There are a lot of other devices with the exact same firmware as these and they do not have this problem, so this is not really a recurrent issue.

Does it means that when the software and hardware is the same, few device will have the issue while other works normal? It is littile strange.

B.R.

Sal

Hi Sal,

While that workaround will prevent the errata from happening, TAxIV is only set if TA.IE is activated and that is not our case. Also, if TAxIV is read, flags with less priority would get overwritten.

Several devices have the same firmware and hardware but a few have presented the problem in very rare occasions. This does not mean that the others work normal. In fact, I do believe that the error could happen on them if the conditions are met.

Best regards,

Tomas

Hi Tomas,

According to the TRM, disable the interrupt will not affect the TAxIV. And the less priority will generates new interrupt after higher one, so I assume it will not overwritten. I currently have no device to test. Maybe you can take a try, and check whether the error occurs again.

B.R.

Sal

After reading the errata and thinking about it, this is what I believe is happening:

1) The CPU begins execution of a read-modify-write instruction and reads an IFG register.

2) A DMA operation begins which halts the CPU.

3) A new interrupt arrives and sets a flag in that IFG register.

4) DMA operation completes and releases the CPU.

5) The CPU writes its altered value to the IFG register. Not noticing that it changed since it read it. Possibly clearing the bit that was just set by hardware.

I assume that there is some mechanism to prevent this problem during normal execution where the read and write happen in consecutive cycles. But fails when there is a delay between the read and write.

Hi Sal,

As I read it, if the interrupts are not enabled (e.g., CCIE is false), the TAxIV will not be set.

I tested it out and it does not set the TAxIV. It's only when the corresponding CCIE of the timer is true that the TAxIV is set.

David,

So, if I understood correctly, the interrupt can only get lost if it arrives at the same time as the RMW operation and the DMA transfer. Wouldn't the flag DMARMWDIS prevent this from happening?

I would expect DMARMWDIS would help, which is why I mentioned it, but the errata doesn't list it as a workaround for whatever reason. (One possible reason is that my guess as to what is going on is wrong.)