Not sure where to post a HAL bug report so posting here. Am using STM32F407zet6 in STM32CubeIDE latest version.
The MX_TIMx_Init function generated by codegen causes a trigger event to occur for the timer. This means that if a timer is set to trigger in response to update from another timer then it will prematurely start during the codegen TIMx_Init functions if it was initialised before the master. This essentially means that successful timer synchronization when update is used as the trigger depends on the ordering of the MX_TIMx_Init codegen function calls.
The reason for the trigger event is as follows:
Let's say TIM1 is the slave and TIM4 is the master (As in my code):
- MX_TIM1_init is called. This sets the slave trigger bit in the register of TIM1 which starts it listening for trigger event from TIM4. TIM1 is not currently enabled (CEN bit of CR1).
- MX_TIM4_init is called.
- TIM4_CR2 register is initialized first with MMS bits set to 000, eg. Reset event is being used to send trigger output
- During MX_Tim4_Init, HAL_TIM_Base_Init is called. During this call the MMS bits is still 000.
- During HAL_TIM_Base_Init, TIM_Base_SetConfig is called. During this call the MMS bits is still 000.
- During the final line of TIM_Base_SetConfig there is the following:
/* Generate an update event to reload the Prescaler
and the repetition counter (only for advanced timer) value immediately */
TIMx->EGR = TIM_EGR_UG; - Before "TIMx->EGR = TIM_EGR_UG;" is executed TIM1 has CR1 has CEN bit of 0, eg. not enabled as expected.
- When "TIMx->EGR = TIM_EGR_UG;" is executed this causes a trigger event as the MMS is set to 000. This causes TIM1, which was initialized first, to detect the trigger event and enable. TIM1's CR1 CEN bit is now 1.
As you can see from the above, this issue means timer slave triggering can happen during the initialisation of timers, rather than when they are started (As seems is the expected behaviour), if they are initialized in an unfavourable order. It would be great if this can be fixed in the HAL so that others do not run into the same issue. As a workaround for now I'm planning to try within "/* USER CODE BEGIN TIM4_Init 1 */" setting the MMS bits to 100 (OC1REF) or some other value which will not be triggered by "TIMx->EGR = TIM_EGR_UG;".
