NUCLEO-F401RE USART2 weird output on the computer serial tools

[RichKnight]

I used the sample code of "en.stm32cubef4-v1-28-0\STM32Cube_FW_F4_V1.28.0\Projects\STM32F401RE-Nucleo\Examples\UART\UART_Printf"

I just printed the "test" in the while(1) loop. but the display of my computer is werid, and I checked the clock and hal level code, the clock frequency and data transfer is correct.

there are data tranferred on the serial port. I captured from SB63 test point and use the PICOscope

The USART2 frequency was set to 9600.

And I think the USART2 use the APB1 bus frequency: 42MHz

GPIO groupA connected to AHB1.

I uploaded the modified code on the github: https://github.com/amazingHH/STM32_UART/tree/main/UART_Printf

I have two boards, and I tested each of them, they have same problem. 

So, is it a USART clock problem?

BTW, I used the KEIL project in the sample code.

[Peter BENSCH · Accepted solution]

Welcome @RichKnight, to the community!

Well, the number of characters received in the terminal per loop corresponds to the number of characters sent, so you have obviously set the correct baud rate. However, the settings of the receiving terminal are missing and I am quite sure that the usual 8-N-1 was set there, right?

But you are sending with 8-O-1:

UartHandle.Init.BaudRate     = 9600;
UartHandle.Init.WordLength   = UART_WORDLENGTH_8B;
UartHandle.Init.StopBits     = UART_STOPBITS_1;
UartHandle.Init.Parity       = UART_PARITY_ODD; // set it to UART_PARITY_NONE
UartHandle.Init.HwFlowCtl    = UART_HWCONTROL_NONE;
UartHandle.Init.Mode         = UART_MODE_TX_RX;
UartHandle.Init.OverSampling = UART_OVERSAMPLING_16;

Regards
/Peter

[Tesla DeLorean]

You're in 7 Bit Odd Parity Mode, is that what you want?

Outputs are not RS232 compatible

Check bit timing with a scope, sending 0x55 'U' repetitively.

Check HSE_VALUE matches that of your design / implementation

[RichKnight]

Thanks, it is really help me!

It fixed! I debuged this whole day!:grinning_face_with_sweat:

Kind Regards

Francois

[RichKnight]

My Parity Mode was set in wrong mode. 

Thanks for your remind!

I think the sample code use the system clock directly.

Kind Regards

Francois