ST32F302RC USART with parity not working

[ra.pamod]

Posted on March 02, 2017 at 08:49

Hello,

I am working on STM32F302RC. I want to use the USART1 with parity enabled both odd/even which is configurable through command.

I am using

USART1

with

baudrate 115200,

data length8 bit ,  parity none with this configuration it works fine. 

stop bit   1,

When I change the configuration of

USART1

to odd or even parity it doesn't work I get junk character on serial termina  as shown below.

sƒß2ØL<DC3> ›'š­ÚšQM¸·»'¹bé·-Hl?S<RS> <DC2> å¹7™JC1<SUB> œî<SO> ƒÃé4 ]\V<SYN> åßóöX-<ETX> ‚, Ø-Hl<HT> <HT> c<STX> �?<CR>

Š Rn-EEº�£{Zª^<SYN> kênæzVH<FF>

•åÓIâQ7$<DC4> <SI> KUad¨�?ËégC1¨Ên-EEº�£{Zª^<SYN> kênæzVH<FF>

•åÓIâQ7$<DC4> <SI> KUad¨�?ËégC1¨Ên-EEº�£{Zª^<SYN> kênæzVH<FF>

•åÓIâQ7$<DC4> <SI> KUad¨�?ËégC1¨Ü]N<ETX> š�?éô<-Rë�•m ._<SYN> å ÔLJHü

What could be the issue? Kindly suggest.

Thank you.

[AvaTar]

Posted on March 02, 2017 at 10:21

You need to change the settings of your serial terminal as well.

[ra.pamod]

Posted on March 02, 2017 at 10:25

Thank you for the reply.

I have changed the setting on serial terminal. If you check on analyzer the terminal is transmitting proper frames when seen on analyzer. 

[AvaTar]

Posted on March 02, 2017 at 11:08

If you check on analyzer the terminal is transmitting proper frames when seen on analyzer. 

'Analyzer' is a quite generic term.

Have you verified (on bit level) that the byte frames sent by the STM32 are correct, i.e. data bits, parity bit, stop bits, frame length ?

If yes, you have a problem with the other side.

[ra.pamod]

Posted on March 02, 2017 at 11:47

[ra.pamod]

Posted on March 02, 2017 at 11:49

Fig.1. Transmitted from desktop to STM32F302RC controller.

Fig.2. Transmitted from STM32F302RC  to desktop.

Bit level I cannot not check,

But the frames sent from STM32 is not correct. Frames sent from Hyper terminal are correct. Frames sent from STM32 shows parity error on Analyzer. The frames from Desktop terminal are shown correct on analyzer.

Analyzer used is Salae logic analyzer.

[waclawek.jan]

Posted on March 02, 2017 at 11:54

What kind of level converter (like MAX232) do you have connected to the STM32?

JW

[ra.pamod]

Posted on March 02, 2017 at 11:59

I am using sp32328. But the frames captured are on the ttl level side.

[waclawek.jan]

Posted on March 02, 2017 at 12:29

OK.

Can we see a capture with longer spaces (delays)  between the transmitted characters, so that we can unambiguously see which one is the startbit?

JW

[AvaTar]

Posted on March 02, 2017 at 13:07

... so that we can unambiguously see which one is the startbit?

I agree.

Have a testcode on your stm32, send two test bytes with the parity bit set respectively not set, spaced by at least one frame length idle time.

[ra.pamod]

Posted on March 02, 2017 at 12:52

I am transmitting '@' every 2 sec as shown below without parity.

fig.1.

fig.2 expanded wave form of each byte.

Below is the wave form with even parity setting:

fig.3.

fig.4. expanded wave form of bytes with even parity

seen on desktop terminal in ascii format  ''Â�À''

In hex format as ''C0''

[waclawek.jan]

Posted on March 02, 2017 at 13:32

Ah, you've been caught by the rather non-conventional 'parity is last data bit' of the STM32 UART implementation...

On the waveform above, you've transmitted 0x40 0x0D 0x0A with 7 data bits and odd parity. Set the terminal to 7O1 and you'll see your transmitted data OK. Please do this just for the fun of it.

Then change the STM32 setting to 9 bits and you'll receive what you intended originally.

JW

[ra.pamod]

Posted on March 02, 2017 at 14:08

It worked.

Why are we required to do this work around?

Is this an errata?

Thank you Waclawek.jan & Ava Tar for your support.

[AvaTar]

Posted on March 02, 2017 at 14:57

Is this an errata?

No, rather a misleading implementation and documentation on ST's side.

[ra.pamod]

Posted on March 02, 2017 at 14:59

Thank you Ava Tar..