MSP430FR2311: Strange/Undocumented behavior when disabling/enabling individual timer interrupts (TB1CCTL0.CCIE)

Hello TJ,

I'm also waiting for official statement for some time now

However, I've run code with "NOP" for a long time and I don't have any problems.

cheers,

Filip

Thanks for the quick reply!  It would be great if we could get an official response from TI after 2 years to close out the thread, but if you've been using the NOP solution for 2 years, that seems to be pretty robust.

Just to confirm, are you doing something like the following?  Just a NOP after disabling the capture/compare interrupt (CCIE)?  Or are you also adding a NOP after re-enabling?  Are you adding the NOP after any other peripheral interrupt disables, just in case?

//disable the TB1 CCR0 capture/compare interrupt
TB1CCTL0 &= ~CCIE;

//NOP to prevent micro from corrupting PC
_NOP();

//perform atomic operation on variable(s) modified by TB1 CCR0 ISR

//re-enable the TB1 CCR0 capture/compare interrupt
TB1CCTL0 |= CCIE;

By memory, I think if you disable peripheral int, you always should put NOP instruction anyway.
When enabling, there is no need.
I'm using these macros :

#define __EVALUATE_STR__(X) #X
#define __EVALUATE_STR2__(X) __EVALUATE_STR__(X)
//#define CLR_BIT_ATOMIC_B(reg, bitn) asm("	BIC.B #" __EVALUATE_STR2__(bitn) ", &" #reg "\r\n	.global " #reg)
//#define CLR_BIT_ATOMIC_W(reg, bitn) asm("	BIC.W #" __EVALUATE_STR2__(bitn) ", &" #reg "\r\n	.global " #reg)

// Use these to disable peripheral interrupts, since NOP is MANDATORY after each peripheral int disable (not documented MSP "feature") :
// https://e2e.ti.com/support/microcontrollers/msp430/f/166/t/895839
#define CLR_BIT_ATOMIC_B(reg, bitn) asm("   BIC.B #" __EVALUATE_STR2__(bitn) ", &" #reg "\r\n   NOP\r\n   .global " #reg) 
#define CLR_BIT_ATOMIC_W(reg, bitn) asm("   BIC.W #" __EVALUATE_STR2__(bitn) ", &" #reg "\r\n   NOP\r\n   .global " #reg)

#define SET_BIT_ATOMIC_B(reg, bitn) asm("	BIS.B #" __EVALUATE_STR2__(bitn) ", &" #reg "\r\n	.global " #reg)
#define SET_BIT_ATOMIC_W(reg, bitn) asm("	BIS.W #" __EVALUATE_STR2__(bitn) ", &" #reg "\r\n	.global " #reg)

But if this is too much, just insert __no_operation() compiler intrinsic after disabling INTs, including timer CCR ones. Whatever works for you.

Compiler should not optimize ASM or intrinsic code in any level of optimizations.

Regards,
Filip

Thanks!  I'll wait a day or two to see if we get some sort of official TI response.  If not, I'll mark your reply as the solution.

Hi TJ,

Any update here, do you still need support?

Thanks!

Best Regards

Johnson

Hi Johnson,

We seem to have a workaround, but it would good if TI could confirm the root cause of the program counter (PC) corruption (see original thread for a lot of troubleshooting and suspected root cause).  TI should also state whether adding a NOP after disabling peripheral interrupts is a guaranteed solution (only you have the ability to check the Verilog).  An open question is whether this issue only applies to this specific peripheral interrupt (timer A/B CCIE) or all peripheral interrupts (other timer interrupts, ADC, RTC, eUSCI, etc.).  Another open question is which parts are affected (may not be important if the universal solution is to add a NOP after disabling peripheral interrupts).  I also think that if a NOP is required, this should be listed as an errata on all affected parts, or the datasheets should be updated to state this requirement.  It would be even better if the compiler would add the NOP, but I don't know if that is feasible.

Had this issue been resolved 2 years ago, it would have saved me at least a week's worth of troubleshooting and frustration (I do read the datasheet and errata!).

Thanks!

Hi TC, 

Thanks for your feedback, I will try to analysis the issue. I will update if any process.

Thanks!

Best Regards

Johnson