cancel
Showing results for 
Search instead for 
Did you mean: 

UART not working at High speed

Rohit007
Associate III

Hello, 

I’m trying to transmit data at 2.5 Mbps (2500000 baud), but I’m not receiving any output. The same code works correctly at 2 Mbps, so the issue only appears when using 2.5 Mbps.

I tested both 64 MHz and 40 MHz clock configurations for the UART. At 64 MHz, CubeMX shows a warning:

“Real Baudrate set at BRR register is 2.461538 Mbits/sec. Error: -1.54%.”

Because of this error, I switched to a 40 MHz configuration, which gives the exact 2.5 Mbps baud rate—but I still don’t receive any data.

Is there any additional configuration required to make the MCU reliably transmit at 2.5 Mbps?

13 REPLIES 13

@Rohit007 wrote:

[...] the UART-to-USB TTL [...]

Which converter, specifically? Are you certain it can actually support 2,500,000 bps? I know for certain the one I use can't, eventhough it can go up to 3Mbps.

You also still haven't answered @Andrew Neil's questions about what you have done to verify your USART is actually producing the output you are expecting. 


@Rohit007 wrote:

I am using the stm32G0C1RET6 board it is a ST EVK board and the supports the UART comm upto 8Mbps. 
i have connected the UART-to-USB TTL to USART2 of this MCU and tried communicating using the Minicom as a serial terminal with Baud rate - 2500000 (you have given one less zero).


I don't see any ST board with that part.

Did you mean the STM32G0C1E-EV ?

It has an STM32G0C1VE MCU.

 


@Rohit007 wrote:

i have connected the UART-to-USB TTL 


What "UART-to-USB TTL" ?

Again, you need to give the full part number so that people can be sure what you're talking about.

How to write your question to maximize your chances to find a solution.

 

Are you sure that your  "UART-to-USB TTL" supports such high baud rates?

How is it wired ? At high speed, this can become significant.

Please show some good, clear photographs of your setup.

 


@Rohit007 wrote:

tried communicating using the Minicom as a serial terminal 


So this - on Linux ?

And are you sure that it supports such high baud rates?

May also depend on drivers?

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.

@Andrew Neil yes  STM32G0C1E-EV is the EVK board i have

 

Gyessine
ST Employee

Hello, @Rohit007 

Apologies for the inconvenience regarding the baud rate.

As a first point, I want to clarify that if you are using a 40 MHz clock, the maximum theoretical throughput achievable is 5 Mbps with an oversampling of 8 bits. The 8 Mbps throughput is achievable only if you use a 64 MHz clock and 8-bit oversampling, as stated in the referance manual page 1003.

However, this baud rate can be limited by the maximum frequency of the GPIO pins being used, which I suspect is one of the root causes to your issue. You need to verify whether the pins you are using can handle the desired frequency that you want to achieve.

For the warning sign, Due to the limited resolution of the USARTDIV register, the actual baud rate generated by the USART may not exactly match the desired baud rate calculated from the clock and prescalers. Table 189 of the referance manual details how USARTDIV is encoded, and the maximum allowable baud rate error tolerance. If the difference between the desired and actual baud rate exceeds these limits, a warning or error is triggered to indicate potential communication issues.

Based on testing conducted on the G0 product, the transmission was capped at 2.25 Mbps with correct data transmission. At 2.5 Mbps, scrambled data was observed, indicating unequal baud rates. This reinforces the conclusion that the issue is caused by exceeding the tolerated error rate.

Gyessine_0-1765277613233.png

To conclude, first please verify that your pins can reach your desired baud rate frequency. Second, verify that you are respecting the tolerated error in baudrate(especially since you are using an HSI clock which will augment this error as @Andrew Neil, clock may have an effect, please consider using an HSE) 
you can calculate it using the BRR register (referance manual page 1051) that you can access using SFR in debug session
Hope that helps

Gyessine

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.