STM32H7S3V8T6 TIM1 prescaler clock clarification

[JShro]

Hi All, 

Hoping someone can clarify my confusion on the clock input for the TIM1 counter...

background:

I am testing Tim1 output compare by toggling PA8 on the micro... - the timer settings are

period = 1600, no clock divisor or prescaler and my clock config is below

On the scope I see PA8 toggling with a period of 25us which seems kind a strange... 

So even if I assume a counter clock of 150Mhz (APB1, APB2 peripheral clocks) and the formula of clock/2*(period+1) as the frequency I should see it toggle at 21.34 us?

 

Why this discrepancy??

 

Thanks!

 

[waclawek.jan]

> by toggling PA8

How?

What's your primary clock source? Have you checked it e.g. by outputting it to a MCO pin?

JW

 

[JShro]

I am using a 16 MHZ crystal (HSE) - I have not checked the output from there good point - I will check it today and report back...

 

Thanks

[waclawek.jan]

I then repeat my question: toggle how?

Even if 1600 cycles sounds like quite a lot; if you toggle the pin as GPIO Output in an interrupt from the timer, using Cube/HAL code compiled without optimization, suboptimal system (e.g. cache) setup, execution from slow (external) memory, it's quite possible this is the good old "that's just too slow" case.

As a first experiment, try 16000 instead of 1600.

Note, that the total period of waveform of a pin being *toggled* is twice as much as the time between successive changes.

JW

[JShro]

Sorry I thought I made it clear but obviously not...

So I have TIM1 configured with a period of 1600 and it is setup to toggle PA8 as the output (via the OUTPUT_COMPARE_CH1) setting - see below

I think you might be right though - maybe it's just latencies - I will try increasing the period and test as you suggested - thanks for all the suggestions

Oh the settings for the output toggle are as below

 

 

[Bob S]

> So even if I assume a counter clock of 150Mhz (APB1, APB2 peripheral clocks) 

That is the clock to the timer's APB bus interface.  The timers themselves clock at 2x that rate (i.e. 300 MHz), as shown in the clocking diagram you posted.  I don't know the STM32H7S3V8T6 specifically, but presuming TIM1 is on the APB1/2 bus like other STM32 families.

That doesn't fix your measured vs calculated discrepancy, but makes the calculated period 10.67us.

 

 

[waclawek.jan]

At this point, in debugger or using some other means (printf?), read out and check/post content of TIM1 registers.

You can also try to output the system clock onto MCO (perhaps divided down not to have too high frequency) and check that.

JW

[JShro]

Sorry got dragged into another project - just getting around to this again...

So I have a breakpoint prior to timer init and all registers are 0

immediately after timer init 

Non zero Registers are as below

TIM1_CCMR1_INPUT = 0x30

TIM1_CCMR1_OUTPUT = 0x30

TIM1_ARR = 0x64

TIM1_BDTR = 0x2002000

TIM1_AF1 = 0x01

TIM1_AF2 = 0x01

Subsequent to that I call  - HAL_TIM_OC_Start(&htim1,TIM_CHANNEL_1);

 

and then the TIM1_CR1 is set to 0x01

 

So still stumped on why the time discrepancy - with the setting of ARR register at 0x64 - I am calculating that the pulse time would be 0.33 us, however I am measuring ~ 1.64 us

 

BTW: I did try a period of 16000 and that gave me a measured pulse time of 252 us, calculated time should be 53.33 us (I think) so looks like it's off by a factor of 5 but that makes no sense to me

[waclawek.jan]

At this point it appears that your clocks are not set up as you expect.

What's your primary clock source? Have you checked it e.g. by outputting it to a MCO pin?

JW

[JShro]

Yes! That was it...

I have a 16MHZ xtal as the clock input, addly enough the MCO pin was showing the correct clock, however the PWR->CFG2 even though it has LDEN set to 1 was not working until you set it again prior to setting the VOS for high speed...

I found a similar issue reported by another user - https://community.st.com/t5/stm32cubemx-mcus/stm32h747-freezes-waiting-for-vosrdy/td-p/304569/page/2

Nevertheless - setting LDEN again prior to the VOS took care of the issue and the timer output is now correct.

Thanks for all your suggestions/help  - As usual occams razor always works wonders :)