Please note: We are aware of an issue affecting replies on the Arm Community forums, which may not be loading as expected.
We apologize for any inconvenience and appreciate your patience while we investigate and work to resolve the issue.
Thank you for your understanding.
Hello, I configured a timer to generate a signal every 1 ms.
See below my code about the timer:
TIM_DeInit(TIMx); // TIM1 Deinitialization * TIM_InitStructure.TIM_Mode = TIM_OCM_CHANNEL_1; TIM_InitStructure.TIM_OC1_Modes = TIM_TIMING; TIM_InitStructure.TIM_Clock_Source = TIM_CLK_APB; TIM_InitStructure.TIM_Clock_Edge = TIM_CLK_EDGE_FALLING; TIM_InitStructure.TIM_Prescaler = 0xEF; // period = 5us TIM_InitStructure.TIM_Pulse_Length_1 = 0xC8; // cycle of 200 period => cycle = 1ms TIM_Init (TIMx, &TIM_InitStructure);
And the statements inside timer's interrupt:
void TIM1_IRQHandler(void) { // port 3 pin 7 activated P37_1; // ACK interrupt TIM_ClearFlag(TIM1, TIM_FLAG_OC1); // clear Output Compare 1 flag TIM_CounterCmd(TIM1, TIM_CLEAR); // Reset TIM1 Counter VIC0->VAR = 0xFF; // write any value to VIC0 VAR }
BUT my oscilloscope measured a period of 1.03 ms instead of the 1ms expected. Normally to generate a pulse every 1.03 ms the TIM_Pulse_Length_1 should be set to 0xCE. As you can see, the difference between 0xCE and 0xC8 is big.
What can be the cause of this timer's inaccuracy ? > Problem in PLL configuration ? > Problem of crystal ? > Problem in timer configuration ?
Has someone the same problem ? In advance, thank you
Hi Stefan, I'm sorry but I didn't understand your question : "SCU_MCLKSourceConfig(SCU_MCLK_PLL); /* MCLK @96Mhz */ Whats the exact value? Is it really 96000000Hz?"
How can I measure that value ? this PLL clock is generated inside the micro, so you can't access it ?
Hi Approved Zeusti, You are right, the counter is reset to 0xFFFC. So you think that I should change the value of my counter to my previous value + 6? I will try and replace my counter value with my counter value + 6 (to take into account the starting point 0xFFFC). (If you are right, I don't understand why ST didn't explain it in its datasheet)
I keep you inform.
Zeusti is right on this.
I briefly got caught out by this unexpected reload value when I first started using the STR9.
It is mentioned in the ST documentation, but I never found an explanation for why this is the reload value.
I guess that someone far cleverer than me decided that this was a good thing to do.
As far as I can remember, the STR9 can also generate an interrupt when the count rolls over from 0xFFFF to 0x0000. Is this tied in with the reload value? Anyone know?
I'm sorry but I didn't understand your question :
Sometimes it says e.g. 96MHz but the real frequency is a little bit higher or lower. It depends on the base frequency, which is used for clock generation, by up-/downscaling. So if the frequency of your OSC/Crystal is not exactly 25Mhz the resulting frequencies e.g. MCLK will not have the frequency you expect.