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 · Accepted solution]

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]

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

[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

[Vincent Onde]

Hi @Community member​ ,

Thanks for your feedbacks, Jan. We are trying to improve little by little our specs, we'll take your points into consideration.

I went through the RMs, there are deviation in 8 reference manuals (RM0038, RM0091, RM0313, RM0364, RM0365, RM0366, RM0451), i.e. TIM16 is mentioned instead of TIM16 OC. The timer specs with be corrected (but the corrections will be visible only when the next RM update will be triggered):

• Internal Connection Table update
• A footnote and/or a small section in the functional description to cover this
• An update of the block diagram, showing than the tim_oc signal can serve as a trigger for a slave timer ITRx input. I prefer to avoid mentioning TRGO, this is confusing (the user will look for the MMS programming bit in a timer which is not TRGO capable).

We'll see also if the timer cookbook app note could include such a new use case.

Last, for what about naming, we're improving this on next generation reference manuals (e.g. the RM0440), to help customers searching for internal signals (names consistent in the whole RM, upper vs lower case to differentiate internal from external signals). The interconnections are listed in the Peripherals interconnect matrix chapter, and at the beginning of the timer chapter.

Best regards,

Vincent

[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]

Hi @Vincent Onde​ ,

Thanks for having a look.

> I prefer to avoid mentioning TRGO

I beg to disagree. Saying that, I understand the ramifications, e.g. also for the nomenclature used in ADC, etc. That's why I suggested to invent another name for "signal-going-out-from-a-timer-to-another-timer(s)'-slave-mode-controller,-whatever-its-source-is", to allow users to search in the RMs and ANs for "timers-which-have-the-signal-going-out....etc...."

Also,

> the user will look for the MMS programming bit in a timer which is not TRGO capable

is easily solved with a remark in narrative and/or the place where the user would expect MMS (CR2 description, or the place of it when there's none).

And, with due respect, I believe I represent better the confused user than you do, But I'm tired arguing and have job to do and bills to pay. And it's true that I am not going to do that name invention and not going to fix all the DS/AN so I better shut up.

> We'll see also if the timer cookbook app note could include such a new use case.

I'd suggest not. I'd suggest a new one (and, please, please, avoid the "modern feel and look" PITA). ANs which attempt to cover too much topic are doomed to fail to convey their message clearly. And, while at it, why don't produce an appnote giving the timer interconnections for all STM32 models - maybe that could be part of the "timers in various STM32 models" AN (number of which I don't know right now and not going to look it up).

Maybe you haven't read my rationale (or rant, if you will) for "dozen for each peripheral", among other things.

> The interconnections are listed in the Peripherals interconnect matrix chapter, and at the beginning of the timer chapter.

And I've ranted quite a couple of times about how insufficient this chapter is (not necessarily related to timers)(this applies to interconnection appnotes for those models where there's no such chapter in the RM - pity there are models where there's none). I'm again too tired to look the particular rants up, especially given the woeful state of this forum - they are too scattered.

> (names consistent in the whole RM, upper vs lower case to differentiate internal from external signals).

Thumbs up.

It's just that the interconnections got lost often there, too. I haven't had deeper experience with the 'G0/'G4 yet, but in the older manuals, often the lowercase signals can be seen as inputs/outputs to/from modules, and there they connect nowhere, and it's up to the user to make guesses...

Maybe I am just not capable of positive criticism, sorry.

JW

[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