Skip to main content
Gavin Baker
Gavin Baker
Associate III
March 14, 2018
Solved

Bug: CubeMX TIM3 initialisation code causes lockup

  • March 14, 2018
  • 4 replies
  • 2535 views
Posted on March 14, 2018 at 08:07

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.

#bug #timer #cubemx #stm32f103 #lockup
This topic has been closed for replies.
Best answer by Imen.D
Posted on March 22, 2018 at 15:06

Hello,

We would inform

you that a new patch for STM32CubeF1 Firmware Package v1.6.1 is published to fix this issue.

Best Regards,

Imen.

4 replies

AvaTar
AvaTar
Senior III
March 14, 2018
Posted on March 14, 2018 at 08:18

I suggest to switch to instruction single step (machine code), and see at which line it fails.

Possibly post the surrounding assembler instruction.

I don't wade through Cube code ...

Gavin Baker
Gavin BakerAuthor
Associate III
March 14, 2018
Posted on March 14, 2018 at 08:31

Ok

meyer.frank

I stepped up until the line it crashes and copied the asm and register state, as below in the screenshots:

0690X0000060A7GQAU.png

0690X0000060A7QQAU.png

This appears to be when the code is writing the flags back to the register with the following line (expanded from the macro):

CLEAR_BIT(AFIO->MAPR, AFIO_MAPR_TIM3_REMAP);

AvaTar
AvaTar
Senior III
March 14, 2018
Posted on March 14, 2018 at 08:43

Dunno why Eclipse (TrueStudio) has integer format view for registers as default ... R3 equals to 0x40010000 at that time.

I don't know the memory map of your device by heart, so can you check if this address is valid, and makes sense in this context ?

Register addresses are listed in the Reference Manual.

If the address is valid, the clock of the peripheral you trying to access might not be enabled. Cube is said to contain some bugs.

Does TrueStudio's 'Fault Analyzer View', as seen in you screenshot, has anything useful to say ?

I
Imen.D
Technical Moderator
March 14, 2018
Posted on March 14, 2018 at 16:04

Hello All,

We are known about this issue and the fix will be integrated in the next patch of STM32CubeF1 v 1.6.1

Sorry for the inconvenience that it may bring.

Best Regards

Imen

"When your question is answered, please close this topic by clicking ""Accept as Solution"".ThanksImen"
I
Imen.DAnswer
Technical Moderator
March 22, 2018
Posted on March 22, 2018 at 15:06

Hello,

We would inform

you that a new patch for STM32CubeF1 Firmware Package v1.6.1 is published to fix this issue.

Best Regards,

Imen.

"When your question is answered, please close this topic by clicking ""Accept as Solution"".ThanksImen"
ZPrib
ZPrib
Associate
October 12, 2018

I have the same problem, using STM32F429, Atollic TrueSTUDIO 9.0, and STM32CubeMX (up-to-date):

The last command, HAL_GPIO_Init() causes lost connection with ST-LINK/V2 (firmware updated):

  GPIO_InitStruct.Pin = Motor2PWM_Pin|Motor3PWM_Pin|Motor1PWM_Pin|Motor4PWM_Pin;

  GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;

  GPIO_InitStruct.Pull = GPIO_NOPULL;

  GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_LOW;

  GPIO_InitStruct.Alternate = GPIO_AF2_TIM5;

  HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);

The instruction in HAL_GPIO_Init() that causes the lost connection is:

GPIOx->AFR[position >> 3U] = temp;

The resulting Console output is:

...

Programming flash.. 

STM32 device: flash programming successful 0x8008e2c 

Error in executing 'step' command ... 

FAILED to REGISTER Values from the target

Target is not responding, retrying...

Target is not responding, retrying...

...

ZPrib
ZPrib
Associate
October 14, 2018

Sorry, my mistake. TIM2, channel 2 is in conflict with JTAG. I changed the timer and now everything works fine.

Terms & ConditionsAccessibility statement