Timer: clearing update event flag can cause flagless input capture interrupt

[dhaselwood]

Posted on October 22, 2011 at 20:31

.ExternalClass8CE9ECEBE1E84036AC5D7158FC9B07F8 p {margin-bottom:0.08in;}

The goal is to measure durations between input captures that exceed the 16 bit counter range by adding counter overflows. There appears to be no way to cleanly do this.  The basic problem is that clearing the update-event interrupt flag is a read-modify register-write type of operation.  During that short window a signal that causes an input capture will turn on the input capture flag, and then have it immediately reset by the write operation that is clearing the update-event flag.  The result is that an input capture interrupt follows, but there will be no flag set.

This situation is rare, but I have caught instances of it happening.  In my particular case I am able to treat an input capture interrupt with no flag set the same as if the flag were set and the results are correct, however in the general case this would not work when more that one input capture in a timer was being used as the routine would not be able to tell which channel was the cause of the flagless interrupt. Is the some way around this problem? Might DMA avoid the problem, (if the DMA channels are not tied up!)? #input-capture #timer

[rmteo]

Posted on October 22, 2011 at 22:25

Why not use the prescalar - or cascade 2 timers to form a 32-bit timer?

[Tesla DeLorean]

Posted on October 23, 2011 at 02:25

One potential issue with M3 designs is a pipeline hazard with the peripheral vs NVIC. If you clear the interrupt as the last thing before exiting an interrupt handler the pipelining, write buffers and disparity in clocks will create a condition where the peripheral is still signalling the interrupt when the M3 decides to tail-chain, causing the handler to reenter (priorities may impact which) and the peripheral will have cleared when you look at it. To avoid this be sure to clear the interrupt upon entry. ie Check source, dismiss, process, leave

As to your issue about knowing which epoch of the 16-bit timer you're looking at. Take a look at using the core cycle counter for a long term timebase, the 32-bit counter has an epoch >1min. The cycle counter is part of the trace unit, and is present in all STM32 parts I've checked.

https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/DispForm.aspx?ID=15729&RootFolder=/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/frequency capture&Source=https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder%3D%252Fpublic%252FSTe2ecommunities%252Fmcu%252FLists%252Fcortex%255Fmx%255Fstm32%252Ffrequency%2520capture%26FolderCTID%3D0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5

[raptorhal2]

Posted on October 23, 2011 at 03:11

Even following Clive's advice, it is still possible to lose an interrupt as Don has discovered. In my case, it was impossible for the frequency to change beyond certain bounds between samples, so I performed a logic test to determine when an interrupt was lost, and adjusted for it.

I previously coded the same application for the Texas Instruments MSP430 running at 8 MHz, and never had the problem. The STM32 is still a better choice, but I wish that ST would find a hardware fix for this. Cheers, Hal

[Tesla DeLorean]

Posted on October 23, 2011 at 03:44

I can't say I've observed it lose interrupts in this fashion, if you push the frequency too high you will saturate the processor.

A better method might be to use encoder/counter mode and periodically sample it, and time stamp using the core counter. Then infer frequency from that. Personally I find these 16-bit timers/counters to be a total cop-out in a 32-bit design. There are so much better ways to build A-B timers,  frequency generators and prescalers.

[dhaselwood]

Posted on October 23, 2011 at 18:55

Clive1: thanks for the thoughts--

The highest possible resolution is required so getting longer times via the prescalar is not an option. Using two counters in cascade would be a possible solution, and one I had not thought of. Having 32 bits takes care of the case where the input captures are one second apart.  If the time intervals would happen to be much longer the problem would arise again.  Basically, it is a mistake in the hardware design.  There needs to be a register where writing a ''1'' clears the flag, not writing a ''0''.  Motorola/Freescale has always done it this way. When we realized what was going on, a friend that has many decades of experience made the comment, in jest, that the hardware designer should be dragged out and flogged.   .

[rmteo]

Posted on October 23, 2011 at 20:24

Every manufacturer's products has pros and cons. Perhaps you may want to look at the NXP LC17xx which has four (4) 32-bit timers with 32-bit prescalers.

[dhaselwood]

Posted on October 23, 2011 at 21:37 Thanks for the thought.  Yes I looked at that NXP series before picking the STM32F103.  The NXP really looked good, then I read the errata.  I discovered that the timer pins that provide for a shaft encoder are ''non-functional''.  So, NXP also has designer to be dragged out and flogged 😉 It looks like in the race to beat the competition with the latest-greatest part, the quality is getting short-changed. The stm32 is a great part, but these little glitches in the design as well as the documentation are certainly detractors.

[rmteo]

Posted on October 23, 2011 at 21:52

As I said, no matter who you go with, you will find issues.  For Cortex-M0/3/4 parts, I currently use FreeScale Kinetis, NXP LPC1xxx and STM32F parts.  Fortunately for me, my development tool chain supports all 3 device families (and several others as well, such as Atmel, Energy Micro, Stellaris, Nuvoton, etc., should the need arise).

[dhaselwood]

Posted on October 23, 2011 at 23:07