2

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);
Mahyar Shokraeian
  • 121
  • 3
  • 1
    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? – Justme Oct 11 '20 at 13:40
  • 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. – Maple Nov 15 '21 at 02:14

1 Answers1

0

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?

Andy aka
  • 434,556
  • 28
  • 351
  • 777
  • 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_ – Mahyar Shokraeian Oct 11 '20 at 14:14
  • 1
    @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. – Chris Stratton Oct 11 '20 at 15:35
  • 1
    @ChrisStratton "*word length 8 bits (including parity)*" seems to be the key here. – Andy aka Oct 11 '20 at 16:24
  • 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. – Chris Stratton Oct 11 '20 at 16:25
  • 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. – Maple Nov 15 '21 at 02:23
  • Andy is very likely right here. The way ST do this UART data length is VERY confusing. Try changing the word length to eight bits if it is not already set to that. Check CR1 and bits M0/M1, to ensure that it's not set to 1:0 . Also never assume the Cube has got it right. – DiBosco Mar 17 '23 at 09:43