2
\$\begingroup\$

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);
HAL_Delay(500);
\$\endgroup\$
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 Oct 11 '20 at 13:40
0
\$\begingroup\$

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?

\$\endgroup\$
4
  • \$\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\$ – Mahyar Shokraeian Oct 11 '20 at 14:14
  • \$\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\$ – Chris Stratton Oct 11 '20 at 15:35
  • \$\begingroup\$ @ChrisStratton "word length 8 bits (including parity)" seems to be the key here. \$\endgroup\$ – Andy aka Oct 11 '20 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\$ – Chris Stratton Oct 11 '20 at 16:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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