Skip to main content
Associate II
March 10, 2025
Solved

STM32H753: Receiving Messages via UART

  • March 10, 2025
  • 8 replies
  • 1168 views

I'm working with an STM32H753 MCU and trying to receive messages from a PC via UART to implement a simple state machine. The idea is that the MCU should switch to different states based on the received message.

Initially, I attempted to use fgets(message, sizeof(message), stdin);, but the buffer named message seems to be empty after receiving, and I get nothing when printing it using printf("\r\nThe sentence is: %s", message);. Is this the correct way to do so?

This topic has been closed for replies.
Best answer by Guenael Cadier

Hi @doronzzz 
I think BSP redefines PUTCHAR service as based on HAL UART Transmit API. But GETCHAR service is not routed to HAL UART Receive API in BSP.
You might have a look at some UART examples as "UART_Console". (Not available in H7 package, but available on other series. you might find code here for instance)

Available code in main.c should be easy to adapt to your case. The goal of this project is to redefine PUTCHAR  and GETCHAR to HAL_UART_Transmit()/HAL_UART_Receive() services.
In same way, you could add your definition of fgets().

Regards

8 replies

mƎALLEm
ST Technical Moderator
March 10, 2025

Hello,

Did you first validate a simple receive example using HAL before going ahead with fgets?

To give better visibility on the answered topics, please click "Best answer" on the reply which solved your issue or answered your question.
doronzzzAuthor
Associate II
March 10, 2025

Yes, UART is configured in the Bsp and the code is automatically generated. printf works fine, and I can read the message using a serial monitor. However, fgets doesn't seem to be blocking, causing 'The sentence is:' to repeatedly print empty string.

Andrew Neil
Super User
March 10, 2025

@doronzzz wrote:

Yes, UART is configured in the Bsp and the code is automatically generated. printf works fine


That shows that TX works - but have you also demonstrated that basic RX works - without the stdin & fgets overheads?

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.
Andrew Neil
Super User
March 10, 2025

Before adding the complications of stdin, printf, fgets, etc have you made sure that your basic UART IO is working?

https://wiki.st.com/stm32mcu/wiki/Getting_started_with_UART

https://wiki.st.com/stm32mcu/wiki/STM32StepByStep:Step3_Introduction_to_the_UART

https://community.st.com/t5/stm32-mcus/implementing-uart-receive-and-transmit-functions-on-an-stm32/ta-p/694926

 

If you have an ST board, CubeMX (standalone, or via CubeIDE) should have ready-to-go examples.

 

Note that GCC defaults to stdout being line-buffered:

https://community.st.com/t5/stm32-mcus-products/no-printf-output-on-uart-before-n/m-p/747968/highlight/true#M267403

I haven't tried it, but that may also apply to stdin ?

 


@doronzzz wrote:

Is this the correct way ?


Very often, handling character-by-character is a better approach ...

 

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.
Guenael Cadier
Guenael CadierBest answer
ST Employee
March 10, 2025

Hi @doronzzz 
I think BSP redefines PUTCHAR service as based on HAL UART Transmit API. But GETCHAR service is not routed to HAL UART Receive API in BSP.
You might have a look at some UART examples as "UART_Console". (Not available in H7 package, but available on other series. you might find code here for instance)

Available code in main.c should be easy to adapt to your case. The goal of this project is to redefine PUTCHAR  and GETCHAR to HAL_UART_Transmit()/HAL_UART_Receive() services.
In same way, you could add your definition of fgets().

Regards

Andrew Neil
Super User
March 10, 2025

@Guenael Cadier wrote:

The goal of this project is to redefine PUTCHAR  and GETCHAR to HAL_UART_Transmit()/HAL_UART_Receive() services.


Actually, the stated goal was, "to receive messages from a PC via UART to implement a simple state machine".

 

I would suggest just using HAL_UART_Receive - without all the added complexities & gotchas! of redirecting stdin ...

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.
doronzzzAuthor
Associate II
March 10, 2025

Yes, you're right! I used HAL_UART_Receive and achieved the desired result. Thanks! The initial issue was that I set up BSP and used automatic code generation, which made direct UART invocation inaccessible.

Andrew Neil
Super User
March 10, 2025

@doronzzz wrote:

I set up BSP and used automatic code generation, which made direct UART invocation inaccessible.


No, that shouldn't make direct access inaccessible.

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.