EVSPIN32G4 - Hall (H1 on PB6) is being pulled to ~2V

[Shane Kent]

Hello -

I've generated a few test projects in the ST Motor Control Workbench using the default settings and my motor's parameters. I've enabled the Hall sensing on TIM4 using PB6, PB7, and PB8. Those three pins are broken out onto J6 of the EVSPIN32G4 development board.

I am using the EC-i 40 motor with embedded Hall sensors (https://www.maxongroup.com/maxon/view/product/449464).

When the Hall sensors are disconnected from the EVSPIN32G4 the voltage of PB6 is being pulled to about 1.95V instead of the expected 3.3V. PB7 and PB8 are at 3.3V.

When the Hall sensors are connected the same behavior is seen. PB6 goes between 0 and 1.95V while PB7 and PB8 go between 0 and 3.3V.

I've attached the project used for this.

Because 1.95V is not above the STM32G431's Vih threshold the PB6 is never being seen as a "high" input. This appears to cause the motor to fault at start-up.

If I generate a basic STM32G431 project in STM32CubeMX, then this behavior is NOT seen. This means that something about the initialization of the STSPIN32G4 projects is causing PB6 to be pulled down from 3.3V to 1.95V.

What is causing this behavior? What can be done to fix this?

Also, are there any example projects built for the EVSPIN32G4 that can be used or do they have to be generated?

- Shane

[Shane Kent]

I determined that this behavior is being caused by the MX_USART1_UART_Init() function call.

When UART_TX_Pin (set as GPIO_PIN_9) is kept in this structure then PB6 inherently gets pulled low via what appears to be a 4.7kΩ pull-down.

void HAL_UART_MspInit(UART_HandleTypeDef* huart)
{ 
....
 __HAL_RCC_GPIOA_CLK_ENABLE();
 /**USART1 GPIO Configuration
 PA9 ------> USART1_TX
 PA10 ------> USART1_RX
 */
 GPIO_InitStruct.Pin = UART_TX_Pin|UART_RX_Pin;
 GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;
 GPIO_InitStruct.Pull = GPIO_NOPULL;
 GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_LOW;
 GPIO_InitStruct.Alternate = GPIO_AF7_USART1;
 HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);
...
}

This doesn't make sense because PB6 is in a completely different port and isn't being referenced in this group of code.

PB6 has the alternate function available for USART1, but that shouldn't have any impact here so I'm curious as to what may be causing this behavior.

[Cristiana SCARAMEL]

Hello @Shane Kent​ 

could you share the version of the ST Motor Control Workbench and STM32CubeMX you are using?

[Shane Kent]

Hi Cristiana -

This project is generated in ST Motor Control Workbench 5.Y.4 and STM32CubeMX 6.6.1. The Firmware Package Version is STM32 FW V1.5.0 (recommended).

I still have not been able to find a solution for this behavior.

-Shane

[Cristiana SCARAMEL]

Hi @Shane Kent​,

Thank you for reporting this issue in the code generation process. 

To overcome this limitation you may follow these steps:

1. after generating the code via ST MC Workbench opens the project (IOC file) using STM32CubeMX.
2. In the "Pinout & Configuration" tab disable the dead-battery function of the UCPD using the checkbox "save power of non-active UCPD".
3. Generate the code within STM32CubeMX

Let me know if these info help you to solve your issue.