2026-03-11 7:27 AM - last edited on 2026-03-19 4:48 AM by mƎALLEm
I am trying to use USART in Proteus, but it is not displaying any characters in the virtual terminal. In fact, nothing is appearing at all.
My workflow was:
I first generated the .ioc configuration using STM32CubeMX.
Then I generated the project and built it in STM32CubeIDE to create the .hex file.
I loaded this .hex file into the STM32 in Proteus.
For USART communication:
I am using USART2.
PA2 → TX
PA3 → RX
I also verified the following:
The baud rate is the same in both:
STM32CubeIDE code
Proteus Virtual Terminal
I even simplified the code to just print a simple string using UART, but nothing appears in the Proteus virtual terminal.
I followed several tutorials, but I still cannot determine what I might be doing wrong.
At the moment, the UART in Proteus is not displaying any characters at all.
I would appreciate help identifying what might be causing the USART not to work in Proteus.
In this project, I am implementing a Publisher–Subscriber model. However, before proceeding further, I want to verify the UART functionality.
Currently:
The UART transmission is not printing anything in the Proteus virtual terminal.
Once this issue is resolved, the next functionality I want to test is receiving data over RX, so that the system can process incoming messages as intended within the Publisher–Subscriber architecture.
At the moment, I would mainly appreciate help in identifying why the UART output is not appearing, and then ensuring that RX reception also works correctly afterward. I have attcahed the whole project found below can you please check if i have correctly configured the ioc file and cube ide code according to which the uart functionality might get disturbed or there is any other reason?I ahve aslo attcahed the proteus usart terminal screen shot its not showing anything .
Solved! Go to Solution.
2026-03-12 3:46 AM - edited 2026-03-12 3:49 AM
Hello @Muhammad_Umer_Asif and welcome to the ST community,
As said by @Andrew Neil Proteus tools (ISIS/ARES) are not something we could support in this community.
I recommend you to use a real hardware and we are happy to help you.
PS: I remember I did a test with Proteus simulation with STM32 and it didn't work even though I set the right STM32 part number, the right clock etc but it didn't work at all .. while with the same application binary it did work in real hardware. That's why I recommend you to use a real hardware.
Otherwise you need to contact Proteus Labcenter in their forum for support.
2026-03-11 8:17 AM
Proteus is an independent 3rd-party product - it has nothing to do with ST.
For support with Proteus, you need to go to Labcenter:
https://support.labcenter.com/forums/
AIUI, Proteus provides both software and hardware debug tools (virtual test instruments) - so have you used them to see what's going on?
eg, have you used a virtual oscilloscope to see if anything at all is happening on your TX pin?
2026-03-12 12:04 AM
Apologies for the delay in responding, as I hadn’t seen your message earlier. I have tested the setup using the Virtual Terminal in Proteus and also with the Oscilloscope, but neither is giving any indication that my code — generated from STM32CubeMX and STM32CubeIDE — is actually sending data via USART to the Virtual Terminal even though I have checked with every possible solution for this i dont know where i went wrong? can you please check the above project folder ?
2026-03-12 3:00 AM - edited 2026-03-12 3:22 AM
So take a step back.
Does a simple LED blink on work in this setup?
Can you just toggle the TX line as a plain GPIO?
@Muhammad_Umer_Asif wrote:I have tested the setup using the Virtual Terminal in Proteus and also with the Oscilloscope
And what about the software debugger - have you stepped your code in that?
PS:
Your screenshot is too low resolution to read clearly.
2026-03-12 3:46 AM - edited 2026-03-12 3:49 AM
Hello @Muhammad_Umer_Asif and welcome to the ST community,
As said by @Andrew Neil Proteus tools (ISIS/ARES) are not something we could support in this community.
I recommend you to use a real hardware and we are happy to help you.
PS: I remember I did a test with Proteus simulation with STM32 and it didn't work even though I set the right STM32 part number, the right clock etc but it didn't work at all .. while with the same application binary it did work in real hardware. That's why I recommend you to use a real hardware.
Otherwise you need to contact Proteus Labcenter in their forum for support.
2026-03-19 4:05 AM
Hello , I have now moved from simulation to real hardware as advised, and I suspect the previous issue may have been related to my use of FreeRTOS with STM32(not sure ). As suggested, I started with a very simple setup using only an LED to move on . I am working with an STM32F103C8T6 using FreeRTOS (CMSIS V2), and I am currently facing an issue where the LED does not behave as expected under FreeRTOS(as it counitnuosly on instead of blinking )
Working behavior:
LED blinks correctly without FreeRTOS using a simple while loop in the same setup .
Flashing and debugging via ST-LINK works without issues.
Problem:
When FreeRTOS is enabled, the LED stays continuously ON instead of blinking under the same hood .
CubeMX configuration:
FreeRTOS enabled (CMSIS V2)
Default task created
USE_NEWLIB_REENTRANT enabled in FreeRTOS advanced settings
SYS timebase tested with:
SysTick
TIM1
GPIO PC13 configured as:
Output ( that is fine as it worked without freertos but stays counitnuoly on with freertos )
Code behavior:
Using osDelay() inside the task
Same toggle logic works outside FreeRTOS but not inside
What I have tried:
Switching between SysTick and TIM1 timebase
Re-generating code multiple times
Verifying task loop logic
Replacing HAL_Delay with osDelay
Question:
Why does the LED remain ON when FreeRTOS is enabled instead of blinking can you please check configurations for freertos ?
Is this related to timebase configuration, scheduler issue, or HAL vs RTOS conflict?
What am I missing in my configuration ?I m so confused here why it might beahvees like this i have attached the project folder can you please check this and inform where is an actual issue underlying?
Any help or suggestions would be appreciated. Thank you.
2026-03-19 4:07 AM
What is the real hardware you are using? a Blue Pill board?
2026-03-19 4:15 AM
yess
2026-03-19 4:36 AM - edited 2026-03-19 4:43 AM
yess
Unfortunately most Blue Pills and other colorful boards may contain a counterfeit STM32 chips.
Therefore ST cannot engage any support on that kind of support.
I suggest you to purchase a ST board with a genuine chip for example NUCLEO-F103RB, so we will happy to help you.
Thank you for your understanding.