Skip to main content
dman
dman
Associate III
July 31, 2017
Solved

Possible HAL F429 UART TX Bug

  • July 31, 2017
  • 3 replies
  • 4590 views
Posted on July 31, 2017 at 13:36

Hi, I am working on my project which requires to send some data over UART.

I have F429ZI Nucleo board with a UART2 configured (see uart2_config image). The UART2 has Interrupts enabled so I can use the HAL_UART_Transmit_IT function.

I am passing an array of uint8_t values. Only 4 bytes. The bytes are getting transmitted via the TX pin as expected, but only 7 bits per byte are transmitted. (see tx_8_bits_no_parity image).

So I got into the F429xx datasheet (

http://www.st.com/content/ccc/resource/technical/document/reference_manual/3d/6d/5a/66/b4/99/40/d4/DM00031020.pdf/files/DM00031020.pdf/jcr:content/translations/en.DM00031020.pdf

 ) and on page 994 the Table 146 clearly states that when the bits M (length = 8bits) and PCE (parity = None) are reset, the UART frame will be: Start Bit, 8 data bits, Stop Bit.

Why is MCU sending only 7 bits when no parity is enabled? So I decided to enable parity in CubeMX and set it to Even.

However, the parity bit just takes up one of the 8 bits, making the data only 6 bits! (see tx_8_bits_even_parity image).

The same table 146, clearly states that the MCU should be sending 7 Data bits and not 6.

How can this be? Am I missing something? I am only trying to send 8 bits of data (0x00 - 0xFF) without parity.

Any advise would be appreciated.

Thanks.

#uart #bug #f4 #cube-mx #hal
This topic has been closed for replies.
Best answer by waclawek.jan
Posted on August 01, 2017 at 13:34

That decoder was written by somebody who does not quite understand how UART works.

The stopbit is transmitted as a whole bit, but it is received by sampling it in its middle (usually with the 3x oversampling). Start bit falling edge detection commences immediately after that. The consequence is, that even if the transmitter's actual bit time is slightly above the receiver's (here: your 'detector''s) expected bit time, the receiver still works flawlessly.

JW

3 replies

Daniel Glasser
Daniel Glasser
Associate III
July 31, 2017
Posted on August 01, 2017 at 00:03

I have found that STM32CubeMX (or at least recent versions) default to 7 bits, no parity, 115200 baud on the UART/USARTs in the generated code.  I make sure I set, or at least check, all of the configuration options in the tool before generating code for a project.

This may not be your case, but it is something to be aware of.

dman
dmanAuthor
Associate III
August 1, 2017
Posted on August 01, 2017 at 10:11

Daniel, thank you for your reply. The default settings are fine. However, what the MCU is outputting on a UART TX line with these settings (defaults from your post) are not what is described in the datasheet (

http://www.st.com/content/ccc/resource/technical/document/reference_manual/3d/6d/5a/66/b4/99/40/d4/DM00031020.pdf/files/DM00031020.pdf/jcr:content/translations/en.DM00031020.pdf

 ).

There is no valid UART/USART frame with 7 data bits and no parity (please see image).

The default configuration in the CubeMX (8-bit Word (M bit = 0) + No Parity (PCE = 0) ) should produce an 8 bit data length, not 7.

0690X00000607mfQAA.png

Kind regards,

Dainius

waclawek.jan
waclawek.jan
Super User
August 1, 2017
Posted on August 01, 2017 at 12:15

It's your decoding (program? scope? LA?) which is flawed, not the UART. There are clearly 1 start bit, 8 data bits and 1 stop bit on the tx_8_bits_no_parity.PNG

JW

dman
dmanAuthor
Associate III
August 1, 2017
Posted on August 01, 2017 at 13:03

Brought my Paint skills into action.

Data transmitted is (decimal): 

[0] = 36

[1] = 2

[2] = 49

[3] = counter, 0 - 255. Due to being only 7 bits, rolls over at 127, but in the software the counter keep going until 255.

0690X00000607ijQAA.png

The only way I can decode the data if I remove the Stop bit from the decoder's configuration and set data length to 8 bits. Then it works fine.

0690X00000607oMQAQ.png

However, my USART2 peripheral configuration does contain a 1 Stop bit.

0690X00000607fgQAA.png
waclawek.jan
waclawek.jan
Super User
August 1, 2017
Posted on August 01, 2017 at 13:11

Stop bit is high.

There is no reason to wait after stop bit, the next start bit proceeds immediately.

JW

Vangelis Fortounas
Vangelis Fortounas
Associate II
August 1, 2017
Posted on August 01, 2017 at 12:27

Hello!

I use UART 2 8n1 configuration on 32f429zi with not any issue.

I use last versions CUBEMX and software pack. and windows 10.

Is it posible to post the .IOC file to help the community reproduce the problem and to solve it?

Check at Run time the Control registers of UART for consistency .

dman
dmanAuthor
Associate III
August 1, 2017
Posted on August 01, 2017 at 12:41

Hi Vengelis,

I have attached the .IOC file. My apologies, I should have thought about it earlier. I am running the Linux Version of Cube MX.

I captured the CRx registers for UART2. The values were:

- CR1 = 8492 (dec), bit set were -> RE, TE, RXNEIE, PEIE, UE

- CR2 = 0

- CR3 = 1 (dec) , bit set were -> EIE.

Vangelis Fortounas
Vangelis Fortounas
Associate II
August 1, 2017
Posted on August 01, 2017 at 13:11

Your settings are right!

I tested it on my 429disco board and Teraterm.

take a look at this figure from RM .(M=0 means 8N1)

0690X00000607iaQAA.png

So .. There is not any error.. Check the polarity of stop bit..

Waclawek.Jan

‌ has right.

Check your Logic analyser or capture equipment you use.

Terms & ConditionsAccessibility statement