TPM rising edge.

[roberto_m]

I'm using a qe32. I'm measuring a square wave, setting Tpm in input capture mode, rising edge. After i've the mean period, between two edge I disable the channel, just before the new edge I set up for rising edge. In this case I get an interrupt also froma a level and non only for an edge!

set off

                TPM1C0SC =  TPM1C0SC_CH0IE_MASK * 0 // disable interrupts
                                    | TPM1C0SC_MS0B_MASK  * 0 // MS=00
                                    | TPM1C0SC_MS0A_MASK  * 0
                                    | TPM1C0SC_ELS0B_MASK * 0 // pin general purpose
                                    | TPM1C0SC_ELS0A_MASK * 0;

set on

        TPM1C0SC = ((TPM1C0SC_CH0IE_MASK * 1) // enable interrupts
                       |( TPM1C0SC_MS0B_MASK * 0)  // MS=00 - input capture
                          |( TPM1C0SC_MS0A_MASK * 0)
                         |( TPM1C0SC_ELS0B_MASK * 0) // rising edge
                         |( TPM1C0SC_ELS0A_MASK * 1));

Where I'm wrong?

Thank you.

[bigmac]

Hello,

Just guessing, but maybe you are not clearing the flag after the last input capture event?  This could mean that an interrupt occurs immediately after the input capture interrupt is re-enabled.  Is the TPM1C0V value the same as for the last input capture value?

Simply writing the value zero to TPM!C0SC will not clear the flag, as a prior read of the register is required before the write process.

The following read-modify-write operation will correctly clear the flag -

TPM1C0SC_CH0F = 0;

Regards,

Mac

[roberto_m]

hello bigmac, thank you and thank you again.

I'm cleaning the flag after the last capture event.Then i read TPM1C0V. Then I disable it. Then i clear the falg again and re-enable TPM1 Ch0. In the new capture (the wrong one) TPM1C0V is different.

I use TPM1C0SC &= ~TPM1C0SC_CH0F_MASK.

I try with TPM1C0SC_CH0F = 0;and have no success.

Roberto

[bigmac]

Hello Roberto,

Both methods are read-modify-write, and either should correctly clear the flag.

Have you checked for short glitches within the input waveform?

Is the spurious interrupt actually an input capture event, and not some other interrupt, or perhaps an input capture interrupt, the processing of which has been delayed by another interrupt?  You could check the delay from the capture event to the current TPM count value (within the ISR), which should measure the interrupt latency, and may give some additional clues.

Regards,

Mac