cancel
Showing results for 
Search instead for 
Did you mean: 

STM32L412 One-pulse Timer not resetting at update event

b.a.
Associate III

Hi all,

I am trying to get a single pulse out of TIM1, triggered by a rising edge on a Pin.

I got it almost working, but the problem is that after the counter reached ARR value, the output channel is reset...

I use PWM mode and the complementary output channel to get the polarity I need.

I could do it with custom IRS, but I quite like the thought to use the dedicated hardware for this task.

In other words, what I want is:

when a rising edge occurs on a pin, the output should go high and stay there for a certain time (CCR), then go low and stay there

The "stay there" part is the one that I don't get working, because on update event the output is reset to low.

Is there any way to change this behaviour and force the output to remain unchanged on update event?

Or another Timer ode that is more suitable for this task?

Cheers,

Bob

11 REPLIES 11
TDK
Guru

> when a rising edge occurs on a pin, the output should go high and stay there for a certain time (CCR), then go low and stay there

Setting CCR=1 and adjusting ARR for the length of the pulse would achieve this.

> The "stay there" part is the one that I don't get working, because on update event the output is reset to low.

But isn't that what you want?

If you feel a post has answered your question, please click "Accept as Solution".
b.a.
Associate III

not really, I get one clockcycle delay with this trick. I'd like to avoid that

Setting the Fast Enable bit for given channel won't help?

JW

b.a.
Associate III

I jus realised I got polarity wrong while describing...

I was playing around with complementary channels and outpu polarity bits.

The second part that TDK quoted should read "because on update event the output is reset to high."

@Community member​ : I don't see how fast enable could help preventing the first clock cycle to occur?

That's the purpose of FE, as described in Particular case: OCx fast enable section of One-pulse mode subchapter of TIM chapter.

The FE "shortcut" has some latency, too; RM states 3 clock cycles, so I guess if you have PSC=0 and CRRx=1 the effect may be none.

I'm not sure there is any better solution than the one suggested by TDK.

JW

b.a.
Associate III

Hi Jan,

setting OC1FE cut down the delay from 1µs to about 110ns - good enough for me.

I still don't quite understand how the one-pulse mode works...

Show us the read out values from timer's registers.

JW

b.a.
Associate III

Timer 1

Triggered by external pin, should give one pulse of several ms

0693W0000059KnGQAU.png 

Timer 2

Triggered by update event of Timer1

should also give one pulse of several ms

0693W0000059KnaQAE.png 

Timer 15

used to generate a rising edge every second to test above 2 timers

0693W0000059KnkQAE.png 

I hope this way of sharing the timer registers is ok...

One-pulse mode is, that the next Update event clears TIMx_CR1.CEN, i.e. stops the counter. Nothing more, nothing less.

(Btw, what I said above is nothing else just rephrased explanation of the OPM bit in TIMx_CR1 in RM. Most of what I say is just that.)

So, I assume your internal timer clock is around 50MHz, i.e. one tick is 20ns. Let's first assume CCMR1.OC2FE is *not* set. For TIM1, you have set PSC=50-1, so timer counter is incremented at 1MHz pace, when enabled. You enable it from the slave-mode controller from ETR, and you've set a 2-clock filter on ETR (bit 8 of SMCR is set), so there's an input sampling uncertainty of 0..1 clock, plus delay of 1 or 2 cycles on the filter (I am not sure how is it exactly implemented), plus some delay in the slave-mode controller, not specified by ST, IMO it will be 1 or 2 clocks; that then sets CR1.CEN and the prescaler and from it the counter start to count. CNT = 0 initially and prescaler is reset from previous action (this detail can be discussed further, but generally after a previous OPM cycle this is true), so it takes 50 cycles of prescaler counting until CNT increments from 0 to 1. At that moment, comparison with CCR2 comes true, and as CH2 is set to Output Compare and PWM1 in CCMR1, the internal OC2REF signal (result of comparison) goes from active to inactive, and as CH2 polarity is inverted in CCER, that would mean the output pin would go from 0 to 1 at that moment - except that channel 2 is not enabled in CCER and also BDTR is set to something not entirely trivial, I'm not sure what's your intention there. In further I assume CCER.CC2E=1 (and CCER.CC2P=1 as is now) and BDTR.MOE=1, so that the output pin reflects the state of the internal logic. There may be some delay from OC2REF to the output pin, presumably 1 clock.

The prescaler+counter continue counting, up until CNT=0x77F=ARR, and prescaler=0x31. One cycle after that, CNT=0, prescaler = 0, Update event is generated, which clears CR1.CEN and both prescaler and CNT stop counting. At the same time, CNT is no more higher or equal CCR2, which means OC2REF goes from active to inactive, thus pin goes from high to low.

In other words, at 50MHz, after the input at ETR pin goes from low to high, the CH2 pin goes from low to high after (2..5 + 50) clocks (i.e. cca 1.04..1.1us), and then after further (50*1919) clocks (i.e. 1.919ms) it goes to low, and stops, waiting for further rising edge on ETR.

Now if CCMR1.OC2FE is set, the incoming edge, after being filtered, goes through a shortcut immediately (more precisely 3 clocks are specified in the RM, although it's not clear from which to which point exactly) to the compare unit and forces the internal OC2REF signal to go as if there would be a match - i.e. for PWM1, it goes from active to inactive, and the inverted output pin goes from low to high. So, the rising edge of CH1 output comes after cca (2+3+maybe 1) clocks (i.e. cca 0.1..0.12us). The prescaler/counter starts counting exactly as in the previous case, and when CNT increments to 1, nothing happens, as OC2REF is already inactive; then after further (50*1919) clocks prescaler/counter stop to count and output pin goes to low in the same way as in the previous case. So, here, the output pulse length is altogether cca 1.920ms (minus the 0.1..0.12us).

JW