On the STM32G441, starting TIM1 CH2 (Set MOE reg) pulls down the PB6 USART1 pin.

[Noko327]

Hi.

I am currently developing a motor control platform using STM32G441 and am facing a problem.

I am controlling a 3-phase motor with TIM1 based on packets from Half duplex USART1 (PB6), but when I Start TIM1 CH2, the USART1_TX pin, which should be unrelated, is pulled down to low level.

Specifically, PB6 is pulled down by executing HAL_TIM_PWM_Start_(&htim1, channel2) or by setting the AF register and MOE register (output enabled).

This occurs only on CH2 and is not reproduced on TIMx CH2 (inverted) or other channels.
No short circuit in the board pattern is observed.

In half-duplex, pull-down to low level during Idle section is a fatal problem.

I have investigated using an oscilloscope, and it behaves as if the TIM1 CH2 pulse is shorted in the MCU with some resistance.

Is this problem an errata of the STM32G441?

Thank you.

[TDK]

TIM and USART are independent. This is most likely a hardware issue. PB6 isn't controlled by TIM1 at all. Unlikely to be an issue there. Some things you can do:

• Measure resistance between PB6 and TIM1_CH2 pin to verify no shorts.
• Set PB6 as GPIO input with pullup. Set TIM1_CH2 as output, and see if PB6 follows it. Look at the GPIO->IDR register.

[Noko327]

Thank you for your reply, Mr.TDK.

There are no shorts on the board, and the resistance values are within the normal range.

I will describe the follow-up information that has been confirmed as a result of the investigation.

Currently, PB6 is set to USART1_TX and is being used in half-duplex mode with idle line interrupts.
With TIM1 CH2 started,
__HAL_UART_CLEAR_IDLEFLAG(pHuart);,
signal interference occurs between the pins.
If the IDLEFLAG is not cleared, the interference does not occur.

Is there anything that could be causing this?

Thank you!

[waclawek.jan]

This is consequence of the USBC PD dead battery mechanism.

As the text says, PWR_CR3.UCPD1_DBDIS to disable this feature (don't forget to enable PWR by setting RCC_APB1ENR1.PWREN prior to this).

JW

[Noko327]

Thank you all for your replies.

As it turns out, this issue has been resolved after updating the STM32G4 firmware to V1.6.1.

Thank you very much!