Using STM32 TIM2 as frequency divider? - Page 1
Forum section: electronics / general

author: thinkfat
author_rank: Unknown
timestamp: March 01, 2020, 08:31:44 pm
content: Hi,in a project I'm trying to eliminate an external ripple counter (HC390) to divide down a 10MHz input to 500kHz (or lower). Going through the manual of the MCU I'm using (STM32F042) I see that TIM2 can get its counter clock from the TI2 input.Idea: Auto-reload down counter with ARR initialized to the desired divisor, and on counter underflow trigger an output on an external pin.I don't want the CPU to be involved - no interrupts, no code executed. I need the output as jitter free as I can have it.Duty cycle of the output signal is not important. A pulse is sufficient, it just has to be synchronized with the input signal edge as tightly as possible.Can the underflow event be routed to an external pin? Maybe output capture mode could be used?BR,Matthias

author: ajb
author_rank: Super Contributor
timestamp: March 01, 2020, 08:45:04 pm
content: Many timer modules have a frequency mode that will do exactly what you're after. Even if it's not a specific mode that the datasheet describes, essentially what you want to do is toggle one of the compare pins on overflow, and this is usually something that can be set up with the right timer and output compare module settings. Even if there's no toggle mode, then you can fake it by setting the timer top value to give the frequency you want, and then set the compare value to something like half of the top value (or whatever fraction you want) to set the duty cycle.Of course these strategies get tricky at very low division values, but with 20x you should be okay. The big question is jitter, and you'll need to carefully check the datasheet and reference manual to figure this out. There could be synchronization issues, or certain timer events may happen synchronously with the system clock, but this is highly dependent on the specific architecture of the peripheral. You'll probably want to do some tests and take some actual jitter measurements before you rely on internal peripherals for things like this.

author: thinkfat
author_rank: Unknown
timestamp: March 03, 2020, 08:56:53 am
content: Hm, yes. The maximum clock is 48MHz, so potentially, if there's something synced to the internal clock (likely), the expected jitter will be in the 20ns range. That's too much.There doesn't seem to be a way to just route the underflow or update events out, so the only way will be to trigger another timer to output a pulse, and that is certainly happening at the granularity of the internal clock. I'll have to look for a different solution.EDIT: maybe I misunderstood. The output capture mode seems to do what I want. I'll have to prototype it, though.

author: dgtl
author_rank: Regular Contributor
timestamp: March 03, 2020, 01:25:10 pm
content: * There is a function of RCC called MCO (microcontroller clock output), that can take the input clock and divide down. This way you can bypass the PLL, just feed your clock to HSE OSC_IN and route out to MCO.* The timer is usually clocked by divided system clock (cpu clock divided down to bus clock). There's a PLL in this path. Some low-power parts have LPTIMER, that support other clocking modes; see the clock tree of RCC.* To output a divided clock, use PWM or output compare mode. Then get your output from TIMx_CHx pin.

author: thinkfat
author_rank: Unknown
timestamp: March 03, 2020, 03:19:38 pm
content: Yes, I think I can do the following:- Feed the 10MHz clock into the external trigger input for the timer,configure the timer to count the trigger pulses instead of the internal clocksource.- Set the timer to auto-reload the desired divisor, e.g. 20 (-1),- Set the capture/compare register to the same value, set the output mode to"toggle"That should give a 250kHz clock on TIMx_CHx.

author: ajb
author_rank: Super Contributor
timestamp: March 03, 2020, 04:59:06 pm
content: The clock speed of the system only becomes relevant if timer updates are synchronous; whether or not that is the case is architecture dependent. If the timer can be incremented and update the compare unit asynchronously then the jitter should be much lower than the system clock period. I don't know how common it is for timer/counter peripherals to be capable of asynchronous operation. This is where you have to study the datasheet and do some tests to be sure. How much jitter can you tolerate? Maybe going to a part with a higher clock speed would be sufficient? Or choosing a part where the timers can be run at a higher frequency than the core (not sure if ST has any such parts; I know Atmel does)?

author: thinkfat
author_rank: Unknown
timestamp: March 03, 2020, 05:05:04 pm
content: I can tolerate jitter equal or below what the 74HC390 creates that is now in the design

author: ve7xen
author_rank: Super Contributor
timestamp: March 03, 2020, 10:33:40 pm
content: I believe the STM32 timer module, when using an external clock, synchronizes it with the APB clock the timer is using, so this probably won't get you anywhere close to the jitter of dedicated logic. If you can generate an APB clock from the 10MHz clock and use that to clock the timer, though, it should be pretty good.

author: thinkfat
author_rank: Unknown
timestamp: March 04, 2020, 12:01:40 pm
content: Quote from: ve7xen on March 03, 2020, 10:33:40 pmI can't see that in the data sheet or reference manual... Maybe it's some implicit limitation I'm not aware of.EDIT: I found it. Bummer, that's not going to work.

author: thinkfat
author_rank: Unknown
timestamp: March 06, 2020, 09:37:33 pm
content: Quote from: dgtl on March 03, 2020, 01:25:10 pmYes, that looks really promising. The MCO prescaler can only divider /128 but that will be enough for my purposes. Also, it looks like I can still use the internal RC and the PLL to generate a 48MHz clock for the system and route the HSE to the MCO prescaler and then out. Worth a try.