Skip to main content
Explorer II
March 10, 2025
Solved

STM32H753: Receiving Messages via UART

  • March 10, 2025
  • 4 replies
  • 1095 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

    4 replies

    Technical Moderator
    March 10, 2025

    Hello,

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

    doronzzzAuthor
    Explorer 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.

    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?

    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 ...

     

    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

    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 ...

    doronzzzAuthor
    Explorer 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.

    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.