AnsweredAssumed Answered

Bug: CubeMX TIM3 initialisation code causes lockup

Question asked by Gavin Baker on Mar 14, 2018
Latest reply on Mar 22, 2018 by Imen D

When the attached ioc file (minimal test case, consistently reproducible) is generated using CubeMX 4.24, firmware package V1.6.0 and built with TrueStudio 9.0.0 the processor locks up when it reaches the call to __HAL_AFIO_REMAP_TIM3_ENABLE() in HAL_TIM_MspPostInit for TIM3. The processor is an STM32F103RF. No additional code was added and no code modified from the original generated code.

 

else if(htim->Instance==TIM3)
{
/* USER CODE BEGIN TIM3_MspPostInit 0 */

/* USER CODE END TIM3_MspPostInit 0 */

/**TIM3 GPIO Configuration
PC6 ------> TIM3_CH1
*/
GPIO_InitStruct.Pin = GPIO_PIN_6;
GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;
GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_LOW;
HAL_GPIO_Init(GPIOC, &GPIO_InitStruct);

__HAL_AFIO_REMAP_TIM3_ENABLE();         // <<===== LOCKUP!

/* USER CODE BEGIN TIM3_MspPostInit 1 */

/* USER CODE END TIM3_MspPostInit 1 */
}

 

The processor seems to lock up and the STLink debugger loses its connection when the red line above is executed. In the debug console, the following output is observed:

 

Debugger connected
Error in executing 'step' command ...
FAILED to REGISTER Values from the target
Target is not responding, retrying...
Target is not responding, retrying...
Target is not responding, retrying...

 

Strangely enough, two error messages appear in red, but then disappear. After much trial and error, I managed to capture the errors in the console:

 

warning: Remote failure reply: E31
Remote failure reply: E31
Quit

 

If I comment out the call to MX_TIM3Init() and skip the above, the generated code continues to work as expected. Similar code for TIM1 and TIM2 don't seem to cause this problem.

Attachments

Outcomes