TPM channel mode: switching from rising edge capture to falling edge capture

[stefanomanca]

Hi, I'm trying to measure a pulse so I config TPM0 to generate edge interrupts. When I switch from rising to falling doing TPM0_C0SC = 0x00U; and then TPM0_C0SC = 0x48U; I see NVIC_ISPR=0X00020000, that means call ISR as soon as I exit from it. This behavior look like a glitch, but I don't know how to switch from rising to falling in other way.

Any idea?

Thank you.

[chris_brown]

Stefano,

I have finally had a chance to look at your question a little bit more.  What you are observing is not a glitch.  The TPM interrupts are queued.  So when the second rising edge happens, that interrupt will be sent to the NVIC immediately upon clearing the Channel Flag.  This is currently documented in the KL25 reference manual.  Please refer to the Channel Flag bit description in the TPM chapter.  I have pasted an excerpt here for your convenience. 

If another event occurs between the CHF sets and the write operation, the write operation has no effect;

therefore, CHF remains set indicating another event has occurred. In this case a CHF interrupt request is

not lost due to the delay in clearing the previous CHF.

And if you could, please mark this post answered with a correct answer by me.  I would like my points for this.  :smileyhappy:

Thanks,

Chris

[stefanomanca]

thank you very much. I don't see the button "correct answer" anymore

[chris_brown]

Stefano,

Trying to capture a rising and falling edge by the method you mention can be very tricky and difficult.  The reason is that you would have to disable the module, then write the CxSC register to change from rising edge to falling edge detection.  In doing so, there can be some delays from writing to the CxSC register to the time that the new settings actually take effect. 

But all of that aside, I have to wonder why you are trying the method you are in the first place.  The TPM does have a setting that will detect a rising or falling edge.  Using this, you wouldn't have to touch the CxSC register to capture both the rising and falling edges. Then, in your ISR, you could sample the GPIO_PDIR register to determine the state of the pin.  This would (I think) be much more reliable than what you are currently doing. 

I'm still a little unclear as to exactly what your application is doing, so I'm not sure that this completely answers your questions.  If not, feel free to reply to this.  I would need a little more detail as to what your application is doing.  Specifically with regard to the pulses that you are generating manually.  (Why generate the pulses manually?)

Hope this helps,

Chris

[stefanomanca]

Hi Chris, you are right! The easiest way is to enable both edges interrupts and then sampling the gpio to tell rising or falling. Ok, BUT now is a theoretical problem. Why is not sufficient cancel the pending bit once? The microcontroller behavior  seems like it could queued the interrupt when I stay (for some reason) in my ISR. Try yourself, generate pulses pattern like I do with a micro(frdm-kl25z in my case) and with another micro capture first pulse and then wait a certain delay inside the ISR, you are going to see that it wont be enough delete the pending bit once....AND I'm not saying to stay in the extreme case where a pulse occurs in the pending bit instant cancellation but  just far from the last edge. The only way to understand what I'm saying is to try.

Sorry for my bad English.

Thank you.

[egoodii]

I still believe you will need to cancel 'pending' in BOTH the TPM and the NVIC.

[stefanomanca]

Don't you guess it is anomalous? Never I've seen that.

[egoodii]

Sorry, I don't understand your statement there at all.  All I was pointing out is that if the TPM generates an interrupt to the NVIC (additional edges) on a priority-level it is already servicing (from first edge), then the associated Pending bit in PR WILL be set, and that WILL cause ISR reentry when that interrupt level is 'cleared' by the exception-return (actually tail-chained to avoid a true 'return', but I digress).  I expect it is valid to hit ICPR to clear a pending-register bit, but presumably ONLY after the 'cause' has been seen as 'no longer true' feeding into the NVIC, and THAT leads to my statement about propagation-delay considerations.  That is, as you have it coded above the 'TPM Clear' and the 'NVIC Clear' are back-to-back, and thru the peripheral-bus write-buffering operations the resultant bus cycles could also be back-to-back, giving maybe just one clock for the TPM-register change to start to wander-over into the NVIC.  I would recommend either disabling the write-buffer for this pair, or find some other 'write' operations to stick between the pair, to insure 'some clocks' propagation time.  And then, too, one would have to 'worry' about any delays internal to the NVIC between said 'PR-clear' write-cycle (again being mindful that write-buffering can place instruction-decode WELL AHEAD of a write-result) and the beginning of the Cortex-core processing of the 'exception return/tail-chaining' (the next step in your code)  to make sure that said attempt-to-clear-pending has removed the TPM-bit influence on the 'next instruction' decisions -- these statements, of course, being what I was referring to earlier about 'assuming' the internal interrupt signal path delays.

This behavior is not an 'anomaly' in any way, it is just the way such hardware works, like the 'very sophisticated' NVIC.

[stefanomanca]

Hi Earl, I'm not so skilled like you, so your explanation is not all clear, but what I ask is why never I see examples where is deleted pending bit in NVIC? Why if arrives a edge interrupt is sufficient to delete the pending bit in TPM register and I must not touch NVIC? The problems arise only when a edge arrives while I am still in my ISR, what happens in that case?

Thank you.

[egoodii]

That is the very PURPOSE of the 'pending' bit in the NVIC, so that 'normal users' of interrupts won't 'miss one' just because they are busy in the ISR processing the 'last one' -- they will simply get another entry to the same ISR to handle the 'stacked up' request.  YOU are trying to do 'unusual' things for which interrupts happen within the ISR that you wish specifically to 'go away', so you have to take extended steps to make that happen.  And all I have been trying to ADD to that process is that in a processor as sophisticated as Kinetis, the 'seemingly obvious' sequence of operations that look like they 'should' perform in a certain order do NOT necessarily 'come out' that way, so you may have run a prior experiment where you had that NVIC_ICPR write in the code, but you still didn't see the expected result of 'no re-interrupt', and all I am saying is that you may need some delays at one point or another before or after that write to give it time to be processed BEFORE returning from the ISR.

[stefanomanca]

Hi Earl, well if you tell me that in unusual situation I must care about NVIC that is not a problem. Do you know any application notes that explain in detail how operates NVIC? And deals with the argument from firmware programmer point of view?

Thank you very much.

[egoodii]

The 'ARM Core' elements are only 'lightly' documented by Freescale in the Kinetis documentation.  For the 'full scoop' you need to go direct to ARM at www.arm.com.  The NVIC can be found at infocenter.arm.com/help/topic/com.arm.doc.dui0553a/DUI0553A_cortex_m4_dgug.pdf section 4.2.  Not exactly an 'apnote' though...

[daniel_ventura]

Hi,

NVIC_ISPR updates to tell you there is a pending interruption to execute; it’s not a glitch. This means that the timer has already finished the count and it’s calling an interrupt.

What I recommend to do is:

• - First configure the NVIC Register (NVIC_ISER |= 0x020000);
• - Then configure the TPM and any other module that you will be using.

Best Regards

Daniel

[stefanomanca]

Hi Daniel, I have not enabled overflow interrupt, only edge interrupt. Try yourself, try to capture a rising edge and then a falling edge. I'm using a frdm-kl25z.

I think TPM peripheral has a bug or at least an anomaly. I'm observing that if I stay a certain period in the isr and in the meanwhile arrives others pulse, it is not enough one only TPM0_C0SC |= (0x80); to cancel the pending bit. I must do:

while(TPM0_C0SC & 0x80){

   TPM0_C0SC |= (0x80);

}

As you can see from the picture if a pulse occurs in the delay, cancel the pending bit once it is not enough. I use the delay to avoid noise pulses after the main pulse.That is just a simulation.

[egoodii]

'Hoping' an ISR can get around to change the function of a channel while you're actively finding edges is tricky at best.  I take it you can't dedicate two pins & channels on opposing edges.  Some other Kinetis members have additional TPM capabilities where a pair of adjacent channels can tie together from one input pin with specific assistance to measure pulse widths.

[stefanomanca]

Hi Earl, I'm sorry but I haven't understood your answer. My problem is theoretical problem. The academic question is: if during the isr arise others  interrupts, in this case more edges, is sufficient clear the pending bit once? My example shows that after the first falling edge come others edges at the end of  the delay, it is not sufficient clear the pending bit once; in fact the toggle of pta4 show me that isr is called again but no edges came after the pending bit cancellation .

[egoodii]

All I am saying is that attempting to 'outsmart' the interrupt hardware this way is going to be very difficult.  You will have to 'guess' how the interrupt travels in the TPM, to the NVIC, and thru ARM exception processing, and try to catch all the timing 'holes' you will encounter between the items that are visible to the CPU.  Trying to filter, and match an edge pair, this way is going to be very tricky.  If you MUST do it with a KL chip, then I can only wish you the best of luck, but I will again strongly recommend moving up to a K-series CPU, where the FTM therein has the ability to filter noisy edges up to 60 bus-clocks, and has specific hardware available to treat two adjacent channels in a 'dual capture' mode to get timestamps on both edges for you.  From that info, further pulse filtering in firmware should be straightforward.

[stefanomanca]

Hi Earl, you are right, to follow the process of interrupt's chain in the extreme cases is tricky, but my case is not an extreme case. When I exit from my ISR (after the first falling edge), the edges occurred in the delay period(see picture) are far, so the eventually pending interrupt raised from edges, can be deleted by TPM0_C0SC |= (0x80); but I see it is not enough. Try yourself. I repeat you, it is only a academic case, I am able to bypass the problem, but may be I have a "hole" in my knowledge or the interrupt mechanism management in the kinetis L  family is anomaly. Why is not sufficient cancel the pending bit once when I exit from ISR if more interrupt events occurred in the meanwhile (note: I put TPM0_C0SC |= (0x80) at the end)???

Will I die with this doubt?

Thank you.

[egoodii]

I see you 'commented out' your write to NVIC_ICPR.  I should assume this would also be necessary to 'kill off' the effects of the edge(s) you are trying to ignore, BUT you are ASSUMING that the internal chip delay between your edge-clear in the TPM, and then farther down the interrupt-processing chain for that 'removal' to reach the NVIC, is NOT 'longer' than it takes to run these two groups of instructions, especially when you try to also consider the effects of internal write-buffering for those activities.  And what happens when one of your real-time edges happens to fall right between those two actions?  It doesn't take an 'extreme case' to fall into these little traps.

[stefanomanca]

Hi Daniel, I have not enabled overflow interrupt, only edge interrupt. Try yourself, try to capture a rising edge and then a falling edge. I'm using a frdm-kl25z.

I think TPM peripheral has a bug or at least an anomaly. I'm observing that if I stay a certain period in the isr and in the meanwhile arrives other pulse it is not enough one only TPM0_C0SC |= (0x80); to cancel the pending bit. I mus