Question regarding clearing K64 FTM channel interrupt

[matthewwatson]

The K64 reference manual describes the CHF channel interrupt flag in CnSC as:

Set by hardware when an event occurs on the channel. CHF is cleared by reading the CSC register while CHnF is set and then writing a 0 to the CHF bit. Writing a 1 to CHF has no effect. If another event occurs between the read and write operations, the write operation has no effect; therefore, CHF remains set indicating an event has occurred. In this case a CHF interrupt request is not lost due to the clearing sequence for a previous CHF.

This implies that no interrupts will be dropped that occur between reading the interrupt flag and resetting it by writing a 1.

However, the processor expert component interacts with this register three times. It is first read to check the status of the flag, the ISR is called, then the &= operation is used to reset the flag, effectively a read operation immediately followed by a write.

My question is does the description in the datasheet guarantee no loss of interrupt events between the first read operation and the write, or only between the second read and the write?

[jeremyzhou]

Hi Matthew Watson,

In the &= operation, a read operation immediately followed by a write is executed.

The process of the operation shouldn't be interfered.

Hope this is clear.
Have a great day,
Ping

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[mjbcswitzerland · Accepted solution]

Matthew

I can confirm that the PE generated code will cause any interrupt event to be lost that occurs between the entry into the interrupt handler and resetting the flag.

1.
IRQ()

{

FTM0_SC &= ~(FTM_SC_TOF);

do stuff...

}

any further interrupt event that arrives after FTM0_SC is read will be pending at the end of the handler and cause it to be re-entered again.

2.

IRQ()

{

(void)FTM0_SC;

do stuff...

FTM0_SC &= ~(FTM_SC_TOF);

}

any further interrupt event that arrives after FTM0_SC is read will reset by the FTM0_SC &= ~(FTM_SC_TOF); and thus lost

3.

IRQ()

{

unsigned long temp = FTM0_SC;

do stuff...

FTM0_SC = (temp & ~(FTM_SC_TOF));

}

any further interrupt event that arrives after FTM0_SC is read on entry will be pending at the end of the handler (will not be reset by the clear of FTM_SC_TOF) and cause it to be re-entered again.

There are some instances where method 2 has an advantage because interrupt arriving faster than the handling rate will not cause the interrupt to always remain pending. In 99.999% of real use 2. is however incorrect code.

PE code may appear to work correctly but it makes sense to always check carefully because it may not satisfy real developments requirements without some "tuning".

Regards

Mark

[matthewwatson]

This is exactly what I suspected, thanks for the clarification Mark!