cancel
Showing results for 
Search instead for 
Did you mean: 

USART line low

jgauthier
Senior

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?

1 ACCEPTED SOLUTION

Accepted Solutions
jgauthier
Senior

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.

View solution in original post

6 REPLIES 6
Andrew Neil
Evangelist III

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?

jgauthier
Senior

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
Senior

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.

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
Up vote any posts that you find helpful, it shows what's working..
jgauthier
Senior

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,

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

0693W000008y9fZQAQ.png