Bug: CubeMX TIM3 initialisation code causes lockup

Gavin Baker · ‎2018-03-14

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...

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

Imen.D · ‎2018-03-22

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".
Thanks
Imen

View solution in original post

AvaTar · ‎2018-03-14

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 · ‎2018-03-14

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:

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 · ‎2018-03-14

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 ?

Gavin Baker · ‎2018-03-14

189694CGIL4

Gavin Baker · ‎2018-03-14

Posted on March 14, 2018 at 09:52

Quick followup - I replaced the macro with some equivalent code that also masks out the write-only bits and everything works fine now:

//__HAL_AFIO_REMAP_TIM3_ENABLE();

CLEAR_BIT(AFIO->MAPR, AFIO_MAPR_TIM3_REMAP | AFIO_MAPR_SWJ_CFG_NOJNTRST | AFIO_MAPR_SWJ_CFG_JTAGDISABLE | AFIO_MAPR_SWJ_CFG_DISABLE);

SET_BIT(AFIO->MAPR, AFIO_MAPR_TIM3_REMAP_FULLREMAP);

Since this is likely not the only place where registers with write-only bits (and undefined read values) occur, I think it would be a great opportunity for ST to audit HAL for other occurrences of similar code that should be masking out certain special bits. There might be other similar gotchas lurking in there...

Thanks!

AvaTar · ‎2018-03-14

Posted on March 14, 2018 at 09:57

There might be other similar gotchas lurking in there...

As said, Cube might contain 'some' bugs. ;)

That's why I don't touch it.

Imen.D · ‎2018-03-14

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".
Thanks
Imen

Imen.D · ‎2018-03-22

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".
Thanks
Imen

ZPrib · ‎2018-10-11

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...

...