Skip to main content
QuangIoT
Associate III
Nov 25, 2024 9:17 AM UTC
Solved

STM32F4 NUCLEO-F429ZI Unable to Communicate with HMI via RS232/RS485

 

I am facing an issue connecting the STM32F4 NUCLEO-F429ZI board to an HMI screen that uses RS232 and RS485 communication standards. The HMI can communicate successfully with my computer, but the STM32 board cannot communicate with the computer except through UART3 and using a direct cable connection. This prevents me from establishing communication between the STM32 board and the HMI screen.

Could you please help me identify what might be causing this issue and how I can resolve it?

Thank you!

This topic has been closed for replies.
Andrew Neil
Andrew NeilBest answer
Super User
Nov 26, 2024 9:56 AM UTC
@QuangIoT wrote:

I'm using this cable and i ensure correct communication standard

That's the USB cable which connects the ST-Link to your computer.

That's what carries the debug/programming connection, and the VCP (Virtual COM Port)

As pointed out by @mƎALLEm, that VCP is connected to USART3 (PD8 & PD9) on the STM32F4 microcontroller.

So, if you want to use USART3 to communicate with any external device, you are first going to have to disconnect it from the ST-Link VCP - that's what the SB5 & SB6 links are for:

AndrewNeil_0-1732614281721.png

AndrewNeil_1-1732614678241.png

https://www.st.com/resource/en/user_manual/um1974-stm32-nucleo144-boards-mb1137-stmicroelectronics.pdf#page=1

AndrewNeil_2-1732614918993.png

 

 

Of course, once you've disconnected them from the ST-Link, then you will no longer be able to communicate over the VCP - you will need a separate USB-to-UART converter.

Similarly, if you use any other UART connection than PD8 & PD9, that will not be connected to the ST-Link and, therefore, will not be accessible via the ST-Link's VCP -  so you will, again, need a separate USB-to-UART converter.

 

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.
View in thread

16 replies

Andrew Neil
Andrew Neil
Super User
Nov 25, 2024 9:34 AM UTC

On debugging serial comms:

https://community.st.com/t5/stm32-mcus-embedded-software/uart-communication-between-stn32h7s78-and-wi-fi-module-ema3080/m-p/746565/highlight/true#M57400

 

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.
mƎALLEm
mƎALLEm
ST Technical Moderator
Nov 25, 2024 9:37 AM UTC

Hello @QuangIoT 

1- The thread is not related to STM32CubeIDE usage to put it in STM32CubeIDE forum board but to the usage of the MCU. Needs to be moved to "STM32 MCUs Products" forum board.

2- The information you provided are insufficient. Need to elaborate and give more details about the HW and the software and what you have tried at this stage.

Thank you.

To give better visibility on the answered topics, please click "Best answer" on the reply which solved your issue or answered your question.
    QuangIoTAuthor
    Associate III
    Nov 25, 2024 9:52 AM UTC

    I have connected the TX of the HMI to the RX of the MCU and vice versa, with GND shared, but data is not being transmitted or received.

    QuangIoTAuthor
    Associate III
    Nov 25, 2024 9:56 AM UTC

    Do you want me to provide anything else? Please give me a request

    QuangIoTAuthor
    Associate III
    Nov 25, 2024 10:40 AM UTC

     

    I have tested the STM32 separately with the computer, but the STM32 does not receive the messages sent from the computer.

     


     

     

    mƎALLEm
    mƎALLEm
    ST Technical Moderator
    Nov 25, 2024 10:49 AM UTC

    At this level, forget about HMI and focus on the UART communication as you said:

    @QuangIoT wrote:

    So, again 

    I have tested the STM32 separately with the computer, but the STM32 does not receive the messages sent from the computer.

    Are you using USART3 with the computer over STLINK? what GPIOs you are using? PD8 and PD9?

    SofLit_0-1732531726216.png

    PS: the spec you provided doesn't give much information (for example mechanical information is useless). But anyway you need at least to achieve the communication between NUCLEO and the computer.

    To give better visibility on the answered topics, please click "Best answer" on the reply which solved your issue or answered your question.
      QuangIoTAuthor
      Associate III
      Nov 25, 2024 11:11 AM UTC

      I'm using USART 3 with my computer via STLINK and communication is normal, but if I switch to using USART2 (PD5 is TX and PD6 is RX) and of course the code will also change from uart3 to uart2 but it won't transmit. receive. During that process, I still have the transmission cable plugged in. Is there any problem that will cause me to not be able to transmit or receive data with uart2?

      mƎALLEm
      mƎALLEm
      ST Technical Moderator
      Nov 25, 2024 11:21 AM UTC
      @QuangIoT wrote:

       I still have the transmission cable plugged in.

      You need to provide what you are using as cable? could you please share an image please? the connection between the Nucleo and the computer?

      To give better visibility on the answered topics, please click "Best answer" on the reply which solved your issue or answered your question.
      QuangIoTAuthor
      Associate III
      Nov 26, 2024 2:08 AM UTC

      Tôi đang sử dụng cáp này và tôi đảm bảo tiêu chuẩn truyền thông chính xác

      Andrew Neil
      Andrew NeilBest answer
      Super User
      Nov 26, 2024 9:56 AM UTC
      @QuangIoT wrote:

      I'm using this cable and i ensure correct communication standard

      That's the USB cable which connects the ST-Link to your computer.

      That's what carries the debug/programming connection, and the VCP (Virtual COM Port)

      As pointed out by @mƎALLEm, that VCP is connected to USART3 (PD8 & PD9) on the STM32F4 microcontroller.

      So, if you want to use USART3 to communicate with any external device, you are first going to have to disconnect it from the ST-Link VCP - that's what the SB5 & SB6 links are for:

      AndrewNeil_0-1732614281721.png

      AndrewNeil_1-1732614678241.png

      https://www.st.com/resource/en/user_manual/um1974-stm32-nucleo144-boards-mb1137-stmicroelectronics.pdf#page=1

      AndrewNeil_2-1732614918993.png

       

       

      Of course, once you've disconnected them from the ST-Link, then you will no longer be able to communicate over the VCP - you will need a separate USB-to-UART converter.

      Similarly, if you use any other UART connection than PD8 & PD9, that will not be connected to the ST-Link and, therefore, will not be accessible via the ST-Link's VCP -  so you will, again, need a separate USB-to-UART converter.

       

      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.
      QuangIoTAuthor
      Associate III
      Nov 26, 2024 10:19 AM UTC

      i transmitted/received data from stm32 to my computer however, i transmitted "123" but stm32 received "67 B3 06". I used uart 2(PD5 Tx, PA3 Rx)

      Andrew Neil
      Andrew Neil
      Super User
      Nov 26, 2024 10:28 AM UTC
      @QuangIoT wrote:

      i transmitted "123" but stm32 received "67 B3 06".

      How are you observing what the STM32 received?

      Receiving "junk" characters is usually due to incorrect baud rate:

      https://learn.sparkfun.com/tutorials/serial-communication/all#:~:text=If%20all%20the%20receiving%20device%20sees%20on%20its%20receive%20line%20is%20garbage%2C%20check%20to%20make%20sure%20the%20baud%20rates%20match%20up

      Is data sent from the STM32 to the PC similarly corrupted?

      Have you used an oscilloscope or logic analyser to see what's actually happening on the wire?

       

      @QuangIoT wrote:

      I used uart 2(PD5 Tx, PA3 Rx)

      With a separate USB-to-UART adapter, then?

      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.
      Terms & ConditionsAccessibility statement