STM32G030K8T6 timer sync problem.

[KYip.2]

1)I am using STM32G030K8T6 running an internal 64Mhz close. I configured TIM1, TIM14, TIM16 & TIM17 as follows:

prescaler= 1000-1

counter mode:=up

counter period = 32000-1

output compare channel 1:

Mode= toggle on match

pulse=1-1

CH polarity = low

CH idle state=reset

2) Running all the timer with the above setting using HAL_TIM_OC_Start(&htimx ,TIM_CHANNEL_1 ) where x=1,14,16 and 17 will produce four 1hz output of the same phase ie on and off at the same time.

3) while the program is running, I change the frequency by manipulate the timer ARR ie TIMx-> ARR = lArr_Count - 1; ( where x=1,14,16,17)

4) Everytime a chance in ARR, I make sure to stop the timer and reset the timer counter TIMx->CNT=0; ie

HAL_TIM_Base_Stop(&htim1);HAL_TIM_Base_Stop(&htim14);HAL_TIM_Base_Stop(&htim16);HAL_TIM_Base_Stop(&htim17);
TIM1->CNT=0;TIM14->CNT=0;TIM16->CNT=0;TIM17->CNT=0;

5) However, the result is not what I expect. What I got was that after a few toggle say between 1Hz and 4Hz, sometimes the one or two of the output is not inphase anymore. It will to continue to be in this phase continue unless I power off and power on the STM32.

6) I have tried the "sledgehammer" approach by including the 

MX_TIM14_Init();
MX_TIM16_Init();
MX_TIM17_Init();
MX_TIM1_Init();

during the change of frequency, but the phase remains the same unless it is a power down and up.

7) Did I miss anything?

[Johi]

Have considered sending ARR and CNT to the debug output window together with some statements when you change the settings?

Beware of the UG update event, and the influence of ARPE (ARR preload). See RM of your processor for more details.

 

[waclawek.jan]

> while the program is running, I change the frequency by manipulate the timer ARR

When? Is this event synchronized with the times?

JW

[KYip.2]

Hi All,

Thank you for all your reply. I have solved the problem. When writing to the timer ARR ie TIMx -> ARR = lArr_Count - 1; I added some 10X(__NOP();) delay padding to make sure the process is complete before the next. Similarly for TIMx-> CNT =0; I added some __NOP(); delay as well. 

It seems running at 64Mhz clock some delay padding is needed for the hardware to complete its task.