STM32F030F4 TIM17 how to set master mode (TRGO source)?

[berendi]

STM32F0 reference manual 13.4.3, TIM1_SMCR description, Table 45 says that setting the TS bits to 011 selects TIM17 as the trigger source. That's fine, because I want to start TIM1 and TIM17 at the same time.

However, the description of TIM17 has no mention of master timer features. There is no TRGO on the block diagram, no MMS bits in CR2.

Is it possible then to start both timers synchronized, or it's just a glitch in the documentation?

[waclawek.jan]

This is a question recurring here for ages, e.g.

https://community.st.com/s/question/0D50X0000AixcFTSQY/undocumented-use-of-internal-trigger-trgo-with-tim14-on-stm32f030c8-

https://community.st.com/s/question/0D50X00009XkhxbSAB/tim15-can-be-synchronized-with-tim16

ST, the fact, that this question comes up here again and again, should really trigger some documentation review mechanisms finally. Yes, I still maintain that the separate timers chapters in RM are a mess, and should be rewritten from scratch and unified into one; but the least you can do in regard of this particular issue is to

• add clear indication of the fact that a particular trigger comes from an OC, in the TRGI tables for SMCR (as it already is in some RMs, see picture below), and
• add a clear indication of TRGO going out of OC in the block diagrams of those TIMs where this is applicable

This fact could be also conveniently highlighted in the "interconnections" chapter in all RMs, where such chapter is available (and to the equivalent appnote for families, where that chapter is absent from RM).

And, while at it, can you please have a look also at the related https://community.st.com/s/question/0D50X00009XkaAv/l4-tim18-trgo-driven-from-the-plain-ocxref-or-the-combined-ocxrefc ?

Thanks,

JW

@Imen DAHMEN​ 

[Imen.D]

@Community member​ : I agree that it deserves some clarification. We will work on this for the next spec updates.

For the bloc diagram, this is slightly different as what you show below: the OC goes to the ITR. There are no TRGO outputs in these timers.

I will come back to you soon with clarification for some points.

Regards,

Imen

[waclawek.jan]

Hi @Imen DAHMEN​ ,

Of course it *is* TRGO.

Okay you may not call them TRGO internally, but that's just more confusing for the users.

We are here talking about user experience, not your internal lingo. And the timers linking is confusing enough and poorly documented enough to add more confusion. So, once users learn that the links are TRGO-to-TRGI, it's wiser to call all the timers outputs towards other timers TRGO even if you internally call only the output from the mux so.

Or invent, some different, particular name for it, and then stick to it strictly.

It means to rewrite much of the RMs/ANs. Not that they don't deserve a thorough rewrite.

The users perspective is very different from the chipdesigners one: the user is now presented with confusing information scattered around quite haphazardly in the RM. There ought to be clear and easily identifiable nomenclature, and that should be used systematically whenever one particular feature (here: timers linking - and yes, I know, others, e.g. tim-to-ADC, too) comes up. Names for these features/signals/whatever should be unique enough so that they can be searched for by textual search, and they have to be adhered to strictly in the narrative, in the registers description and in the diagrams.

Can please the person talking through you come and discuss here directly?

Thanks,

Jan

[Imen.D]

Hello All,

Thank you for pointing this out to me, this is helpfull for us to improve our products/resources.

I'm analyzing all your feedback/comments and I will come back to you with update.

Best Regards,

Imen

[waclawek.jan]

Thanks, @Imen DAHMEN​ .

Jan

[Vincent Onde]

@berendi​ 

Hello,

Yes, I confirm the 2 timers can be synchronized.

The STM32 timers with one channel only (i.e. TIM10, TIM11, TIM13, TIM14, TIM16, TIM17) do not have the circuitry to act as a master: no TRGO output, nor MS programming bits.

Still, they can be used as a master using their output compare output (e.g. tim17_oc), when it is connected to the ITR input of a slave timer (here TIM1).

The only point to care about is that there are 2 clock cycles delay between the starts due to internal synchronization. The 1st trick is to initialize the slave timer (here TIM1) to 2 instead of 0.

The 2nd point to take care about is that the TIM17 output will be set as soon as the MOE bit is set, before starting the counter. This can cause some unpredictable offset. To avoid this, the (pseudo) master timer must be started with a null duty cycle. The whole system will start (synchronized), when the user will write a non-zero duty cycle in the master.

I have to admit this is not obvious, we will have to document this behavior.

Best regards,

Vincent

[waclawek.jan]

@Vincent Onde​ 

> The only point to care about is that there are 2 clock cycles delay between the starts due to internal synchronization. The 1st trick is to initialize the slave timer (here TIM1) to 2 instead of 0.

Looking forward to the AN, dealing with this issue in great details, especially with when cross-APB timers connections are involved (and including the real impact of MSM bit, which I faintly recall to have tried and found to be insufficient).

:)

Jan

[waclawek.jan]

@Vincent Onde​ ,

> The 2nd point to take care about is that the TIM17 output will be set as soon as the MOE bit is set, before starting the counter. This can cause some unpredictable offset. > To avoid this, the (pseudo) master timer must be started with a null duty cycle. The whole system will start (synchronized), when the user will write a non-zero duty cycle > in the master.

With this, you've got me lost again.

My impression was, that the output of timer towards GPIO consists of two signals: Level, and Enable. And I though what you call OCx - and goes as the-signal-which-you-don't-call-TRGO to the slave timer - is the former, i.e. Level; while the latter, Enable, is connected to MOE (pending other BDTR bits are in their default state, break signal is inactive, etc.).

But now you say that MOE impacts the master-slave process?

Can you please clarify?

JW

[Vincent Onde]

​Hi Jan,

The MOE only impacts the master-slave process when we are using TIM_OC1, this is not true when TRGO is used.

The TIM_OC1 is taken after enable circuitry (exactly as the signal that goes to the I/O).

If we are in PWM mode 1 (output high when counter is below compare), the TIM_OC signal will rise as soon as the MOE bit is set, before starting the counter.

Best regards,

Vincent

[waclawek.jan]

Hi Vincent @Vincent Onde​ ,

I still don't get it. Maybe I'm exceptionally dumb.

So, you say, that the TIM17_OC as input to TIM1's slave input multiplexer, comes directly from the *pin*? Because how I see it is, that as long as MOE=0 (and other bits in BDTR are at their reset values), the pin, if set to AF to TIM17_CH1, ought to be threestated (HiZ), or am I wrong?

And I can't quite see why would a threestateable signal be an input to the slave-mode mux, and how exactly would there the Hi-Z state be interpreted.

Could you please sketch a diagram?

Thanks,

Jan.