STM32H747I-DISCO Virtual Com USART Example

Louie88 · ‎2025-01-27

Hi,

If I understand right USART1 is used in STM32H747I-DISCO board for VCOM. I could not find any example for my board. I would like to want for an 8-byte host command using:

HAL_UART_Receive_IT(&huart1, hostCommand.buffer, 8);

Once a command is received then I process it, I create the answer and wait for the next command. So simple.

Noe: on CN13 pin 13 I see the command from my PC on scope, but the HAL_UART_RECEIVE_IT() never receives anything.

Can sombody send me a short example?

Thanks,

Louie

Louie88 · ‎2025-01-28

Yes Andrew, I did it. The board "knows" itself.

Louis

Louie88 · ‎2025-01-28

Okay, thanks for this note.

Louis

Louie88 · ‎2025-01-28

Hi Andrew,

No, HAL_UART_IRQHandler() ? does not receive any data.

Yes, there is an HAL_UART_ErrorCallback(), but I do not have USART1 interrupt, so neither, parity, frame or other errors won't happen, because USART1 "thinks" PB7 is RX but for VCOM we should specify PA10 as RX. There is no RX signal for USART1. (Thanks for Guenael's note).

Louie

Andrew Neil · ‎2025-01-28

@Louie88 wrote:
USART1 "thinks" PB7 is RX

Well, it's your code which had told it to use PB7 for RX.

@Louie88 wrote:
but for VCOM we should specify PA10 as RX. There is no RX signal for USART1. (Thanks for Guenael's note).

So has that now resolved your issue? If so, mark Guenael's post as the solution:

https://community.st.com/t5/community-guidelines/help-others-to-solve-their-issues/ta-p/575256

Louie88 · ‎2025-01-28

Hi Andrew,

It is not so simple.

CobeMX automatically generates PB7 = Rx, but the discovery card uses PA10 = Rx. This is Guenael's fix.

But, this is only one half of the fix.

The other half is from TeslaDeLorean:

HAL_UART_Receive_IT() returns immediately, you have to catch the content in the callback.

Which means I have read and store each received bytes int the UART1 ISR because HAL_UART_Receive_IT() does not do it for me.

With these two fixes the communication works nice.

Thanks for the help from all of you!

Best regards,

Louis

Andrew Neil · ‎2025-01-28

@Louie88 wrote:
CubeMX automatically generates PB7 = Rx, but the discovery card uses PA10 = Rx.

Again, did you tell CubeMX that it's an STM32H747I-DISCO board?

When you tell CubeMX that it's an STM32H747I-DISCO board, it should know what pins to use for the VCP.

If it's using the wrong ones, that's a bug in CubeMX.

@Guenael Cadier

Guenael Cadier · ‎2025-01-28

@Andrew Neil, @Louie88
I checked with latest CUBEMX 6.13.0, starting a brand new project from "Acces to BAORD Selector", then picked up the

Then, i choose to initialize all peripherals to their default configs.
And I could check that PA9/PA10, are properly assigned to USART1 TX/RX.

So no issue in CubeMX from my point of view.

Best regards

Andrew Neil · ‎2025-01-28

@Louie88 wrote:
HAL_UART_Receive_IT() returns immediately, you have to catch the content in the callback.

This is the whole point of receiving under interrupt - precisely so that your code does not have to sit and wait for the entire operation to complete before it can carry on

@Louie88 wrote:
Which means I have read and store each received bytes int the UART1 ISR

No, you don't.

In your call to HAL_UART_Receive_IT(), you give a pointer to a buffer. The HAL takes care of reading each received byte, and putting it into that buffer for you.

When the specified number of bytes has been received, the HAL calls the HAL_UART_RxCpltCallback() function - this is your signal that the reception is complete, and all the received bytes are available in your buffer and ready to use.

If an error occurred during the reception, the HAL would call the HAL_UART_ErrorCallback() function to alert you.

Andrew Neil · ‎2025-01-28

Indeed.

I just tried creating a project for the STM32H747I-DISCO board, and CubeMX clearly identifies the pins connected to the ST-Link VCP:

@Louie88

Louie88 · ‎2025-01-28

Thanks for the info. I can't explain why my CubeMX V6.13.0 works different than yours, except my project (RCTDigitalClock, see 2nd and 3rd screen shots) originally was created in TouchGFX.

This will be complicated... sorry.

I created RCTDigitalClock project in TouchGFX app because I needed the graphical library support to display content of the Real Time Clock on the LCD of STM32H747I-DISCO board. The USART1 is needed to make the date/time settings easier. Using a simple terminal app I can send the current date/time in "yyyy.MM.dd[space]hh:mm:ss" format string to the RTC chip. This way we do not need to use the built-in date/time editor (Screenshot #2)

In TouchGFX I added a simple Screen1 with background image and some text areas for demo. I generated the code form TouchGFX and tested it in the Simulator and in the discovery board. There was no problem at all.

However I noticed the followings:

TouchGFX Created the project in C:\TouchGFXProjects\RCTDigitalClock folder which is out of my default workspace (C:\Users\[UserName]\STM32CubeIDE\workspace_1.17.0\RCTDigitalClock .
TouchGFX Created a `STM32CubeIDE` folder with CM4 and CM7 folders.
TouchGFX Created a `STM32H747I-DISCO.ioc` file. Why not RCTDigitalClock.ioc?

The next step was how I can add the RCT and USART1 to my project. The obvious answer was to edit the `STM32H747I-DISCO.ioc` file. I opened `STM32H747I-DISCO.ioc` file in STM32CudeMX and added the RTC then USART1. When I enabled the USART1 then STM32CubeMX automatically created PB7 as Rx pin. This is the bug or issue or whatever you call it. This was teste at least 20 times.

When I closed STM32CubeMX then it offered to open the STM32CubeIDE project (with STM32H747I-DISCO name. Why?) in STM32CubeIDE app.

I am not sure that I did everything regularly (officially) but this is how I got my working project. And yes, the project is dedicated to STM32H747I_DISCO board which was selected in TouchGFX app. (Not it STM32CubeIDE)

Can you repeat this?

Thanks,

Louis