Hi.
I'm using a MSP430F5308.
If I enable the interrupt for a timer with an assignment like:TA1CCTL1 = CCIE; // istruction A (it also clear CCIFG)
can i avoid to clear the interrupt flag with
TA1CCTL1 &= ~CCIFG;
before instruction A?
With istruction A, are all TA1CCTL1 bit get updated all together?
Do interrupt get accepted in synchrony with MCLK? I think that they are accepted asynchronaly because when you are in Low Power MCLK could be off.
I know that when an interrupt is accepted, any currently executing instruction is completed before serve the interrupt. But can an interrupt be accepted asynchronaly in the middle of a MCLK clock period (and actually served at the end of the current istruction)? In that case, if during the execution of istruction A, CCIE is set a little bit before CCIFG get cleared, i can get a unwanted interrupt.
I know that everything it's a little bit confused but i can not think a proper answear about that.
Regards,
Carloalberto
Hello Carloalberto,
Yes, you can use instruction A to both clear and enable the interrupt. You do not need to clear CCIFG first.
Assuming CCIE was clear before that instruction, you will definitely not get a TA1CCTL1 interrupt at the end of that instruction.
Carloalberto Torgheleif during the execution of instruction A, CCIE is set a little bit before CCIFG get cleared, i can get a unwanted interrupt.
No, that can't happen. There is no race condition between the clearing CCIFG and setting CCIE as long as both occur on the same MCLK edge.
Interrupts are accepted on MCLK edges. When considering low-power modes, it helps to remember that an active interrupt request actually enables MCLK.
Here's an example for you to consider. Let's say CCIFG is already set, and we do this:
TA1CCTL1 |= CCIE; NOP();
The ISR doesn't actually execute until after the NOP. You can't enable the interrupt and acknowledge it on the same MCLK edge.
Now consider another example. Let's say again that CCIFG is already set, and we do this:
TA1CCTL1 |= CCIE; TA1CCTL1 &= ~CCIFG;
The interrupt still happens after the CCIFG instruction! The CPU has already decided to acknowledge the interrupt.
Hope that helps.
Jeff
withx=y;you assign the complete value y to the variable or register x, overwriting all bits in teh target.
if you just want to set a single bit, leaving the others untouched, usex |= y; (it sets all bits in x that are set in y, but doesn't clear bits in x which aren't set in y. This is a logical OR operation and is performed as a bit set instruciton (BIS) by the processor.
The opposite is the bit clear (BIC) isntruction, which does not have a direct coutnerpart in C.The logical AND operation (& or &=) clears all bits that are not present in both operands. However, it can be achieved by binary inverting (~) y first, so all bits are set except the onces in Y, before performing the AND. This way all bits in x remain untouchedexcept for the ones that were set in y.
Carloalberto TorgheleDo interrupt get accepted in synchrony with MCLK? I think that they are accepted asynchronaly because when you are in Low Power MCLK could be off.
_____________________________________Before posting bug reports or ask for help, do at least quick scan over this article. It applies to any kind of problem reporting. On any forum. And/or look here.If you cannot discuss your problem in the public, feel free to start a private conversation: click on my name and then 'start conversation'. But please do so only if you really cannot do it in a public thread, as I usually read all threads. And I prefer to answer where others can profit from it (or contribute to it) too.
Thank you all for your reply.
Therefore i can be sure that it is not dangerous to clean IFG flag and enable the interrupt in the same assignment.
To be clear:
suppose that CCIFG is set in TA1CCTL1 and that i want to enable CCIE but that i want to service an interrupt just for a event that will follow the interrupt enable instruction.
I can do
TA1CCTL1 = CCIE; // zzz
and be sure that even if CCIFG was set before zzz, there will not be any interrupt (until another future event will trigger it).
Carloalberto TorgheleI can doTA1CCTL1 = CCIE; // zzzand be sure that even if CCIFG was set before zzz, there will not be any interrupt (until another future event will trigger it).
Jens-Michael GrossYes.
Jens-Michael Gross In theory, there might be a small timeframe (a racing condition) that may cause the system to assume an interrupt while the new values are written, but this happens at a moment when the CPU won't accept an interrupt anyway. When the CPU is checking for a pending interrupt, this moment is long gone, so it is safe.
In theory, there might be a small timeframe (a racing condition) that may cause the system to assume an interrupt while the new values are written, but this happens at a moment when the CPU won't accept an interrupt anyway. When the CPU is checking for a pending interrupt, this moment is long gone, so it is safe.
Do you now where can I read a detailed explanation about all this things? The mcu reference manual doesn't go in detail.
Carloalberto TorgheleDo you now where can I read a detailed explanation about all this things
Carloalberto TorgheleThe mcu reference manual doesn't go in detail.
After all, the MSP is no consumer product (even if it is used in consumer products). Remember, 'engineer' comes from 'ingenious' and not from 'engine operator' :)
I know that it's low level mcu design and probably I will never really need this information.
But It was just for curiosity. Of course I have some guess about it, but it'd like to read something "official" and reliable.
Anyway, I can imaging that there is not any document that explain low level implementation in detail. I have just tried.
Thanks for everything!
Carloalberto TorgheleI know that it's low level mcu design
Carloalberto TorgheleBut It was just for curiosity
Carloalberto Torghele I can imaging that there is not any document that explain low level implementation in detail.