cancel
Showing results for 
Search instead for 
Did you mean: 

USART in Proteus not displaying any characters / Issue also with Blue Pill board

Muhammad_Umer_Asif
Associate II

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:

  1. I first generated the .ioc configuration using STM32CubeMX.

  2. Then I generated the project and built it in STM32CubeIDE to create the .hex file.

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

1 ACCEPTED SOLUTION

Accepted Solutions

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.

To give better visibility on the answered topics, please click on "Accept as Solution" on the reply which solved your issue or answered your question.

View solution in original post

8 REPLIES 8
Andrew Neil
Super User

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?

 

 

 

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.

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 ?

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.

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.

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.

To give better visibility on the answered topics, please click on "Accept as Solution" on the reply which solved your issue or answered your question.

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.

What is the real hardware you are using? a Blue Pill board?

To give better visibility on the answered topics, please click on "Accept as Solution" on the reply which solved your issue or answered your question.

yess 

 

 

 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.

 

To give better visibility on the answered topics, please click on "Accept as Solution" on the reply which solved your issue or answered your question.