cancel
Showing results for 
Search instead for 
Did you mean: 

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

berendi
Principal

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?

14 REPLIES 14

@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

​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

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.

​Hi Jan,

When MOE=0, the I/O is not necessarily in Hi-Z, it depends on the OSSI bit:

OSSI=0: control is released (I/O in Hi-Z)

OSSI=1: output disabled (still controlled by the timer, low impedance, with inactive state defined within the timer).

The signal for triggering the slave is taken just before the output pin, in the AF controller.

Best regards,

Vincent

Hi Vincent, @Vincent Onde​ 

> When MOE=0, the I/O is not necessarily in Hi-Z, it depends on the OSSI bit:

I know, that's why I wrote above "and other bits in BDTR are at their reset values".

> The signal for triggering the slave is taken just before the output pin, in the AF controller.

OK, so take my above questions as a clear indication that the fact that MOE impacts this signal *is* confusing, and ought to be treated properly - I'd suggest a footnote to the modified general timer diagram as outlined above (i.e. with the output not-at-all-TRGO signal drawn), pointing out the fact that OC1 behaves exactly as described in the Output control bits for complementary OCx and OCxN channels with break feature table later in the registers description subchapter.

But than that table ought to be reworked to give clear description of *all* signals (OCx, OCxN, OCx_OE, OCxN_OE) for *all* states. It's not so now, including the utter garbage The output state is defined by the GPIO controller and can be High, Low or Hi-Z., the confusing footnote saying When both outputs of a channel are not used (control taken over by GPIO controller), the OISx, OISxN, CCxP and CCxNP bits must be kept cleared {why would that be so?) and the subsequent note referring to AFIO controller in a RM where no AFIO controller is mentioned anywhere else than the TIM registers (I am talking particularly about Table 205 in RM0351 Rev.6 - and yes, AFIO *is* mentioned elsewhere, again a garbage reference to AFIO_MAPR register in DBG).

I have drawn that table for myself: I took the 'L476 off my shelf, took some simple timer-related code (btw. concocted to investigate https://community.st.com/s/question/0D50X00009sWbv9SAC/masterslave-problem-on-tim3-in-stm32l476-slave-not-counting-when-itr2-selected ) and tested all states. The MOE=0 and OSSI=1 is particularly funny when it comes to the OC1 which-is-not-TRGO-at-all signal. I am looking forward to ST publishing the revised timer chapters soon, so that I can then compare my findings to the official documentation.

JW