I'm using the newest version of stm32cubemx to config my hardware. I'm using a Waveshare STM32H743 dev board and it's completely healthy and uClinux works(I can easily communicate with it using that usart) on it.

so, as I stated, it's not a board or connection specific problem. I guess maybe it's a bug in cube that is configuring the registers in a wrong way. but when I read the registers, I couldn't understand how this is happening.

my configuration

I tried to change parity, stop bits, baudrate and ... randomly on the receiver(that is my pc) but it wasn't helpful. I think there is a problem with the 7th bit. because 7th bit has the value of "128" and the ascii codes that I receive on my computer are wrong and it seems that 128 is added to them.

my program in while(1) loop:

char h[]="hello";
HAL_UART_Transmit(&huart2, h, 5, HAL_MAX_DELAY);
  • 1
    \$\begingroup\$ What are your PC settings? What software is used on PC? What is the currently used clock source of STM32 and do you know if it is accurate enough for UART transmissions? Have you looked at the waveform with an oscilloscope? \$\endgroup\$
    – Justme
    Commented Oct 11, 2020 at 13:40
  • \$\begingroup\$ There are two ends in this connection. If one looks OK then it is sensible to check the other one, and not by "randomly" changing it. \$\endgroup\$
    – Maple
    Commented Nov 15, 2021 at 2:14

1 Answer 1


Possibly it might be this: -

enter image description here

The above implies that the transmission has a word length of 7 bits plus a parity bit. But, you have parity disabled (none) and so it might only be transmitting 7 bits followed by the stop bit (always 1). That could give your PC the impression that the stop bit is a data bit and that it is high. Have you tried setting your PC to receive 7 data bits and no parity bit?

  • \$\begingroup\$ thanks for your answer! but I tried it and it didn't work well. when I set my pc to receive with no-parity \ one-stop-bit \ 7-bits it receives this hqq}h5qq}hqq}hqq}... and when I set it to receive with no-parity \ two-stop-bits \ 7-bits it receive the data better but with weird letters(randomly captilized and '\n' not working) : heLLOhellOHEllohELLoHElloHEllohellOhELloHello \$\endgroup\$ Commented Oct 11, 2020 at 14:14
  • 1
    \$\begingroup\$ @andyaka Where in this do you see any evidence that only 7 data bits would be transmitted? As far as I can see, these settings should result in a defacto-standard N,8,1 transmission. This posting seems to cloud the issue more than help resolve it. \$\endgroup\$ Commented Oct 11, 2020 at 15:35
  • 1
    \$\begingroup\$ @ChrisStratton "word length 8 bits (including parity)" seems to be the key here. \$\endgroup\$
    – Andy aka
    Commented Oct 11, 2020 at 16:24
  • \$\begingroup\$ And no parity set. So it's N,8,1. Or to put it another way, from the provided controls, how would you set things to achieve N,8,1? Given how overwhelmingly dominant that setting is, the gui wizard has to support it, and there's no alternative to the settings pictured for how it would do so. \$\endgroup\$ Commented Oct 11, 2020 at 16:25
  • \$\begingroup\$ Word length in Cube does not include stop bit(s). The setup in OP screenshot is really ubiquitous for 8-bit communication. I agree with @ChrisStratton, something else is going on either in code or on PC. I suspect the code OP provided is not the actual one. From the comment above: "and '\n' not working", but there is no '\n' in the code. \$\endgroup\$
    – Maple
    Commented Nov 15, 2021 at 2:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.