Skip to main content
Associate
Oct 16, 2026 10:51 PM UTC
Question

STM32CubeMX v6.18.1 fails to generate init code when USER LABELS are assigned

I’m developing a motor driver that uses hall quadrature encoder on the motor shaft. I implemented the code described in a tutorial here… https://deepbluembedded.com/stm32-timer-encoder-mode-stm32-rotary-encoder-interfacing/

The example runs fine with PF12 (TIM20_CH1) and PF13 (TIM20_CH2) connected to the quadrature signals.

Except, if I assign User Labels M3_HALL_A and M3_HALL_B respectively, the initialization code is not properly created and the PF12 and PF13 remain in their reset configuration (pin mode analog MODER values are 0x03).

Is there some extra step required if User Labels are assigned, or is this a bug to be fixed?

Thank you.

4 replies

Ghofrane GSOURI
ST Technical Moderator
Oct 19, 2026 9:10 AM UTC

Hello ​@mc.townsend 

Could you please provide your IOC in order to check your configuration ?

I will be waiting for your feedback.

THX

Ghofrane

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
Associate
Oct 19, 2026 4:10 PM UTC

Hi Ghofrane, thank you for the note.

2 IOC are provided here.

1 - One is working properly without User Labels assigned.

2 - The other that is not working with User Labels applied on PF12, PF13, and PF9.

Perhaps I have made a simple error. Please let me know. I will want to use the User Labels if possible.

Ghofrane GSOURI
ST Technical Moderator
Oct 20, 2026 9:57 AM UTC

Hello ​@mc.townsend 

After checking the generated code 

The definitions correctly map M3_HALL_A to PF12 and M3_HALL_B to PF13, using GPIO_PIN_12/GPIO_PIN_13 with port GPIOF

Both versions configure PF12 and PF13 with the same GPIO mode, pull setting, speed, and AF2 for TIM20, then initialize them on GPIOF. The User Labels introduce no behavioral difference in this block.

Same for M3_PWM_Pin

 

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
Associate
Oct 20, 2026 7:22 PM UTC

I believe I have determined the problem.

This started as a Motor Control Workbench project. I have a BLDC motor connected as M1.

I have a secondary brushed motor that I am writing a custom driver for. I have called it M3.

When I referred to the IO for PWM and HALL signals as M3_HALL_A, M3_HALL_B, M3_PWM, and some other pins that start with ‘M3_’ the auto-generated MX code interpreted those as being associated with motor drivers and so within mc_tasks.c the function mc_lock_pins() included my User Label pins in the list to be locked.

MX_Motor_Control_Init() calls mc_lock_pins(), and that occurs before my labelled pins were initialized on TIM15 and TIM20.

So the PWM and HALL functions were not initialized properly.

The order of the init functions from MX is:

MX_GPIO_Init();

MX_DMA_Init();

MX_ADC1_Init();

MX_ADC2_Init();

MX_ADC5_Init();

MX_CORDIC_Init();

MX_TIM1_Init();

MX_TIM2_Init();

MX_USART1_UART_Init();

MX_MotorControl_Init();

MX_SPI1_Init();

MX_USB_Device_Init();

MX_TIM15_Init();

MX_TIM20_Init();

 

So, I have found a solution to the problem. Don’t refer to these as ‘M3_xxx’.

But I have 2 questions:

1 - can I modify the order of the MX-generated initializations?

2 - can I alter the MX code generation to modify what is included if I were to assign a brushed motor as, for example, M3.

Thank you.