cancel
Showing results for 
Search instead for 
Did you mean: 

I ran printf over UART but the results were not displayed in Tera Term

t-oka
Associate III

 

Hello everyone

I'm using stm32f207ztg6 and want to do printf using UART, but it doesn't show up in Tera Term.
How can I solve this problem?

■ Program used

 

// *-*-*↓main()-*-*-*-*-*-*-*-*-*-*-*-*
setbuf(stdout, NULL);
while (1)
{
/* USER CODE END WHILE */
printf("Hello World\r\n");
HAL_Delay(1000);
/* USER CODE BEGIN 3 */
}
// *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

int _write(int file, char *ptr, int len)
{
HAL_UART_Transmit(&huart2,(uint8_t *)ptr,len,10);
return len;
}

static void MX_USART2_UART_Init(void)
{

/* USER CODE BEGIN USART2_Init 0 */ /* USER CODE END USART2_Init 0 */ /* USER CODE BEGIN USART2_Init 1 */ /* USER CODE END USART2_Init 1 */ huart2.Instance = USART2; huart2.Init.BaudRate = 115200; huart2.Init.WordLength = UART_W ORDLENGTH_8B; huart2.Init.StopBits = UART_STOPBITS_1; huart2.Init.Parity = UART_PARITY_NONE; huart2.Init.Mode = UART_MODE_TX_RX; huart2.Init.HwFlowCtl = UART_HWCONTROL_NONE; huart2.Init.OverSampling = UART_OVERSAMPLING_16;
if (HAL_UART_Init(&huart2) != HAL_OK)
{
Error_Handler();
}
/* USER CODE BEGIN USART2_Init 2 */

/* USER CODE END USART2_Init 2 */

}

 

■STLink: STLink Virtual COM Port

■Situation
When HAL_UART_Transmit is executed, HAL_OK is returned, but nothing is displayed in "Tera Term".

1 ACCEPTED SOLUTION

Accepted Solutions

Hello @t-oka ,

First, before starting the printf usage over UART, you need to validate the UART transmission by for example just sending a couple of characters using HAL_UART_Transmit().

Second, you need always to check the schematics or board's user manual before suspecting an issue in the FW.

According to the schematics of MB1137 the UART instance connected to STLink-VCP on NUCLEO-F207ZG (MB1137) is USART3 and not USART2:

SofLit_0-1726844839253.png

So you need to select USART3 instead of USART2

Refer to this printf example. on NUCLEO-F207

Hope it helps.

To give better visibility on the answered topics, please click on "Accept as Solution" on the reply which solved your issue or answered your question.

View solution in original post

6 REPLIES 6
SofLit
ST Employee

Hello,

You didn’t tell which board you are using?

To give better visibility on the answered topics, please click on "Accept as Solution" on the reply which solved your issue or answered your question.

Hello!
I am using a Nucleo board.

Which Nucleo board?

Please see the posting tips - including how to properly post source code:

https://community.st.com/t5/community-guidelines/how-to-write-your-question-to-maximize-your-chances-to-find-a/ta-p/575228

 

Before adding the complications of printf, have you got this working by just doing the HAL_UART_Transmit direct?

If that doesn't work then, clearly, printf is never going to work!

 

Also note that stdout is line-buffered - ie, the output won't appear until you send a newline...

 

PS:

https://community.st.com/t5/stm32cubeide-mcus/retarget-printf-on-stm32g070rbxx-cortex-m0/m-p/721066/highlight/true#M30729

Hello @t-oka ,

First, before starting the printf usage over UART, you need to validate the UART transmission by for example just sending a couple of characters using HAL_UART_Transmit().

Second, you need always to check the schematics or board's user manual before suspecting an issue in the FW.

According to the schematics of MB1137 the UART instance connected to STLink-VCP on NUCLEO-F207ZG (MB1137) is USART3 and not USART2:

SofLit_0-1726844839253.png

So you need to select USART3 instead of USART2

Refer to this printf example. on NUCLEO-F207

Hope it helps.

To give better visibility on the answered topics, please click on "Accept as Solution" on the reply which solved your issue or answered your question.

I was able to solve the problem with the help of your schematic and example.
Thanks.

>You should always check the schematic or the board's user manual before suspecting a FW problem.
→You're right...
Also, see the tips in your posting - how to properly post source code, etc:
I'll be careful about that too.


@t-oka wrote:

>You should always check the schematic or the board's user manual before suspecting a FW problem.


That's probably the key difference between embedded C (particularly on small microcontrollers), and C on "big" systems (Linux, Windows, et al) - you need to understand the hardware context.

 

See also:

https://community.st.com/t5/stm32-mcus-embedded-software/ds18b20-sensor-detection-via-one-wire-1-wire-protocol/m-p/729960/highlight/true#M55863

 

#HardwareMatters #EssenceOfEmbedded