Skip to main content
jgauthier
Senior
May 25, 2022
Solved

USART line low

  • May 25, 2022
  • 6 replies
  • 1103 views

Hello,

 I'm working with an STM32G05, on a very simple custom board. I expose both USARTs to external headers.

USART1 seems to be operating fine - in that I can send/receive data.

However, USART2 is not.

When I inspected the TX line I discovered it was low, even at boot.

I check for anything that might be pulling it to ground, and there isn't anything on the board itself.

Is there something with the processor that could be causing this?

This topic has been closed for replies.
Best answer by jgauthier

I believe I have found a bug in cubeMX code generation.

Code generated for USART1 looks like this:

 GPIO_InitStruct.Pin = GPIO_PIN_9|GPIO_PIN_10;
 GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;
 GPIO_InitStruct.Pull = GPIO_NOPULL;
 GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_LOW;
 HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);

The code generated for USART2 looks like this:

 GPIO_InitStruct.Pin = GPIO_PIN_2|GPIO_PIN_3;
 GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;
 GPIO_InitStruct.Pull = GPIO_NOPULL;
 GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_LOW;
 GPIO_InitStruct.Alternate = GPIO_AF1_USART2;
 HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);

I added

GPIO_InitStruct.Alternate = GPIO_AF1_USART1;

to the initialization structure for USART1 and now it works as expected.

6 replies

Andrew Neil
Super User
May 25, 2022

What board are you using?

If it's a custom design, has it ever worked before?

If you change the TX line to be just a plain GPIO, can you set it high & low?

A complex system that works is invariably found to have evolved from a simple system that worked.A complex system designed from scratch never works and cannot be patched up to make it work.
jgauthier
jgauthierAuthor
Senior
May 25, 2022

Thanks for that idea. The custom board has never been used - it's brand new.

I made PA9, and PA10 both GPIO Outputs and they are both toggling correctly.

I set them back to USART1, and USART1_TX (PA9) stays low.

jgauthier
jgauthierAuthorBest answer
Senior
May 25, 2022

I believe I have found a bug in cubeMX code generation.

Code generated for USART1 looks like this:

 GPIO_InitStruct.Pin = GPIO_PIN_9|GPIO_PIN_10;
 GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;
 GPIO_InitStruct.Pull = GPIO_NOPULL;
 GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_LOW;
 HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);

The code generated for USART2 looks like this:

 GPIO_InitStruct.Pin = GPIO_PIN_2|GPIO_PIN_3;
 GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;
 GPIO_InitStruct.Pull = GPIO_NOPULL;
 GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_LOW;
 GPIO_InitStruct.Alternate = GPIO_AF1_USART2;
 HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);

I added

GPIO_InitStruct.Alternate = GPIO_AF1_USART1;

to the initialization structure for USART1 and now it works as expected.

Tesla DeLorean
Guru
May 25, 2022

It does look wrong, but you originally stated that the issue was with USART2, not USART1

What did that failing code look like?

Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
jgauthier
jgauthierAuthor
Senior
May 25, 2022

You're right. I made a mistake because for some reason I thought it was the secondary UART. After posting a bug I received this response:

https://community.st.com/s/question/0D53W000019Ctw4SAC/uart-not-configured-properly-for-stm32g061

It was confirmed by ST that it is a code generation issue,

Andrew Neil
Super User
May 26, 2022

If the issue is now resolved, please mark the solution:

0693W000008y9fZQAQ.png

A complex system that works is invariably found to have evolved from a simple system that worked.A complex system designed from scratch never works and cannot be patched up to make it work.