2018-05-19 01:48 AM
Hi,
I can not get the input compare mode working as expected. I need to use TIM2 CH1 as trigger to measure the frequency of external pulses. I have used the methode on a STM32F091 where it works fine.
RCC and GPIO are initialized. And I will get a CC1IF interrupt as soon as I connect the external signal source BUT CCR1 is always 0! It seems to me the counter is not counting. My code to set up the counter:
#define VEL_CLK 10000000 //System is running at 200 MHz PSC is set to 4
TIM2->CCMR1 = TIM_CCMR1_CC1S_0 ; // ch 1 for input capture
TIM2->SMCR = TIM_SMCR_ETP | TIM_SMCR_SMS_2 | TIM_SMCR_TS_2; // reset mode on ch1TIM2->CCER = TIM_CCER_CC1P | TIM_CCER_CC1E;
TIM2->PSC = (APB1_CLK / (VEL_CLK)) - 1; // Timer clock
TIM2->CR1 = TIM_CR1_CEN; // Start timer TIM2->DIER = TIM_DIER_CC1IE; NVIC_SetPriority(TIM2_IRQn,0); NVIC_EnableIRQ(TIM2_IRQn);The TIM2 registers after intialization (see attached file).
Any suggestions very appreciated!
Best regards
Dirk
2018-05-19 03:04 AM
If ARR=0, the timer won't count.
If this is the reset value, you should raise complaint at ST, as the RM says otherwise.
JW
2018-05-19 04:26 AM
Many thanks Jan! You have improved my day a lot! I have struggled with the timer issue since yesterday.
ARR is 0 after reset
ARR is 0 after MX_TIM2_Init
After setting ARR to 0xFFFFFFFF it works as expected
How do I raise a complaint at ST? I have never met so many issues with a ST processor before as with the STM32H743.
Other findings so far apart from TIM2 issue:
Peripherals using PLL2P will not work as DIVP2EN seems to be stuck at 0
Peripherals using PLL3R will not work as DIVR3EN seems to be stuck at 0
Best regards and many thanks
Dirk
2018-05-19 08:25 AM
'
I can not get the input compare mode working as expected.'
what is 'input compare'? there is 'input capture' and 'output compare' but what exactly is 'input compare'?
2018-05-19 01:07 PM
what exactly is 'input compare'?
:D
Yep, this selective blindness.
How do I raise a complaint at ST?
Here, starting a new thread, clearly stating the case, best accompanied a minimal but complete compilable example exhibiting the problem. Or through the web support form. Or through your FAE.
JW
2018-05-23 04:59 AM
Hi
Handzic.Dirk
,As suggested by Jan, please create a new thread where you describe the PLLx related issue.
-Amel
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
2018-05-28 07:38 AM
Hi
Handzic.Dirk
,As soon as TIM2 clock is enabled, the ARR value is set to its correct reset value (0xFFFF FFFF). But with the call of 'TIM_Base_SetConfig', it will be set to the defined 'Period' in your code.
-Amel
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
2018-05-28 11:30 AM
Amel,
How do you know Dirk calls TIM_Base_SetConfig()? I see no such indication in his initial post, and in his second post he asserted that
ARR is 0 after reset
Jan
2018-05-29 01:07 AM
Hi Amel,
you are right. I checked ARR att the start of main() and it reads 0x00000000, I checked it again after calling MX_TIM2_Init and it is still 0x00000000.
After your reply I have single stepped through the HAL initialization code and indeed after HAl_TIM_Base_MspInit() ARR reads 0xFFFFFFFF and is reset in in the next function TIM_Base_SetConfig() again.
For upcounter mode it does however dont make sense why ARR = 0 would stop the counter from operation.
Dirk
2018-05-29 01:15 AM
Corollary: never trust anybody who hints he/she uses Cube. :)
Hats off, Amel. The hint was faint and came only in the second post.
For upcounter mode it does however dont make sense why ARR = 0 would stop the counter from operation.
It does: the upcounter counts from 0 to ARR (inclusive), so here the counter counts from 0 to 0 (so does not change at all).
JW