2019-12-03 12:36 PM
I use timer 6 with stm32F7 MCU. The project is generated with CubeMx.
Here are the initialize function:
static void MX_TIM7_Init(void)
{
TIM_MasterConfigTypeDef sMasterConfig = {0};
htim7.Instance = TIM7;
htim7.Init.Prescaler = 0;
htim7.Init.CounterMode = TIM_COUNTERMODE_UP;
htim7.Init.Period = 124;
htim7.Init.AutoReloadPreload = TIM_AUTORELOAD_PRELOAD_ENABLE;
if (HAL_TIM_Base_Init(&htim7) != HAL_OK)
{
Error_Handler();
}
sMasterConfig.MasterOutputTrigger = TIM_TRGO_RESET;
sMasterConfig.MasterSlaveMode = TIM_MASTERSLAVEMODE_DISABLE;
if (HAL_TIMEx_MasterConfigSynchronization(&htim7, &sMasterConfig) != HAL_OK)
{
Error_Handler();
}
}
and the interrupt callback function:
void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim)
{
if (htim->Instance == TIM7)
{
HAL_GPIO_TogglePin(LED_GPIO_Port, LED_Pin);
}
}
In main I call HAL_TIM_Base_Start_IT(&htim7); before entering the empty while loop. The AHPB clock is 8 MHz. The output I got at LED_Pin is at 10 kHz no matter how I changed the ARR value. When I run the debugger, the UIF flag in SR register was not cleared in the IRQ Handler although __HAL_TIM_CLEAR_IT(htim, TIM_IT_UPDATE); is called. Does anyone know what the problem is? Did I miss something when setting up the timer?
2019-12-03 12:38 PM
I read a topic with similar problem that said the software does not have enough time to clear the flag, so I added a while loop after the clear statement but it didn't help.
2019-12-03 02:08 PM
What happens if you drop Cube/HAL and write this normally?
If "AHPB clock" means that APB runs at the same clock as AHB, 124 cycles may be too short to enter/exit the ISR, especially with the added Cube/HAL burden.
Do you have DBGMCU_APB1_FZ.DBG_TIM7_STOP set?
JW