UART 16550 IP - Stick parity problem

[Patrik78]

Hello,

in my company we're facing a problem while using UART 16550 IP in stick parity mode: on LSR register we set SP=1, EPS=1, PEN=1 in order to use MARK_PARITY.

While in transmission everything works as expected, in receiving data the UART behave as in LSR register the SP bit is not set.

So, it works as mark parity in Tx, and parity even in Rx.

Any suggestions? Is this a correct behaviour for the IP?

We're using Quartus 18.1.

[ShengN_Intel]

Hi @Patrik78 ,

Yes, this is the correct behavior for that IP. Check this document https://www.intel.com/content/www/us/en/docs/programmable/683130/22-3/lcr.html (image):

When even parity is selected (EPS = 1), the PARITY bit is transmitted and checked as cleared.

Thanks,

Best regards,

Sheng

p/s: If any answer from the community or Intel Support are helpful, please feel free to give best answer or rate 4/5 survey.

[Patrik78]

Deart Sheng,

the problem is that it seems the parity is not checked as cleared, but it seems to check the number the number of logic '1's received.

We see no difference while receiving, in setting the LCR with SP=1 or not: with EPS=1, it seems to check an even number of logics '1's.

Are we misunderstanding something?

[ShengN_Intel]

Hi,

This is the expected behavior based on document. The SP bit works in conjunction with the EPS and PEN bits. Means SP bit is more passive and it depends on EPS & PEN bits. So at receiving, when even parity is selected (EPS = 1), the PARITY bit (SP) is checked as cleared. When odd parity is selected (EPS = 0), the PARITY bit (SP) should be checked as set.

Thanks,

Best regards,

Sheng

p/s: If any answer from the community or Intel Support are helpful, please feel free to give best answer or rate 4/5 survey.

[Patrik78]

Hello Sheng,

I try to be more clear describing the problem we are facing.

Referring to the 16550 IP we are using the Stick Parity function (par 10.2) either in Tx either in Rx.

In our design we want to stick the parity to “1” for some Tx data and to “0” for all the other Tx data.  

On the receiver side we have two Uart in parallel. The first configured with stick parity fixed to “0” and the second with stick parity fixed to “1”

In the first Uart the stick the parity set to “0”. We want to store only the received data with stick parity fixed by the Tx Uart to “1” (not related to data bits value) and discard all received data with stick parity fixed by the Tx Uart to “0” (LSR bit 2).

In the second Uart the stick the parity set to “1”. We want to store only the received data with stick parity fixed by the Tx Uart to “0” (not related to data bits value) and discard all received data with stick parity fixed by the Tx Uart to “1” (LSR bit 2).

In detail when I configure the Stick Parity to "0" on the Receiver Uart, I assume that the parity bit of the received data will generate a parity error in the LSR register (bit 2="1") only if the received data has the parity bit ="1" independently by the value of the data bits ( not calculated but stick to the programmed value in the LCR register)

In the following our test bench with two 16550:

• the first Uart is configured to transmit data with stick parity set to "1" (LCR Bit5 SP="1", Bit4 EPS="0", Bit3 PEN="1")
• the second Uart is configured to received data with stick parity set to "0" (LCR Bit5 SP="1", Bit4 EPS="1", Bit3 PEN="1").

In our test the second Uart receive the data in polling mode reading and storing the LSR register to check the LSR Bit0 (DR) to find if a new data is available.

If a receive data is ready, we check the in the stored LSR register the bit 2 (PE) that should be set to "1" for each received data (reset automatically to "0" after the reading of LSR register).

In our test we see that the LSR register bit 2 (PE) sometimes is "0" and sometimes is “1” independently from the stick parity programmed in the receiver Uart.

Can you check our test and support us to use the stick parity function in the receiver?

[ShengN_Intel]

Hi,

Check this https://www.intel.com/content/www/us/en/docs/programmable/683130/22-3/lsr.html:

Parity Error (pe):

Since the parity error is associated with a character received, it is revealed when the character with the parity error arrives at the top of the FIFO. It should be noted that the Parity Error (PE) bit (LSR[2]) will be set if a break interrupt has occurred, as indicated by Break Interrupt (BI) bit (LSR[4]). In this situation, the Parity Error bit is set depending on the combination of EPS (LCR[4]) and DLS (LCR[1:0]).

Break Interrupt (bi):

This is used to indicate the detection of a break sequence on the serial input data. Set whenever the serial input, sin, is held in a logic 0 state for longer than the sum of start time + data bits + parity + stop bits. A break condition on serial input causes one and only one character, consisting of all zeros, to be received by the UART.

In order for Parity Error (PE) bit to be set, the Break Interrupt (BI) bit has to be set first.

Thanks,

Best regards,

Sheng

p/s: If any answer from the community or Intel Support are helpful, please feel free to give best answer or rate 4/5 survey.

[Patrik78]

Hello Sheng,

sorry but I don't understand how your suggestion is fitting with our test bench configuration.

Could you please be more specific and give us more details?

[ShengN_Intel]

Hi,

You say that the LSR register bit 2 (PE) sometimes is "0" and sometimes is “1”. So when Parity Error (PE) bit is "0", does the Break Interrupt (BI) bit being triggered? If the Break Interrupt (BI) bit is not triggered, then the Parity Error (PE) bit is "0" that's expected.

[Patrik78]

Hello Sheng,

in our application we don't use break signal, so I expect the BI bit to be always 0 and that's what happen.

While it seems parity bit is handled as expected in odd, even mode it seems it does not work in Stick parity mode (mark or space)

Here some data: in case I receive in MARK stick parity a 0x55 with '0' as parity bit, I expect to get 0x65 in LSR (assuming we are not transmitting, bit TMTE e THRE are '1'), and that's exactly what I read.

But if I receive a 0x57 with '0' as parity bit, I expected to still get 0x65 in LSR... but in this case I read 0x61.

So at the end it seems receiving in MARK stick parity mode does not work.

Could this be possible ? Any ideas ?

[ShengN_Intel]

Hi,

The hexadecimal 0x55 and 0x57 you mentioned represent the combination of start bit + data bits + parity + stop bits right? If so, 0x57 should have '1' as parity bit right?

[Patrik78]

Hello Sheng,

the hexadecimal 0x55 and 0x57 represent only data bits, not considering start, parity and stop bits.

In the example I was describing I receive a 0x55 (or 0x57) data, followed by the parity bit always '0'.

As the receiver is configured in MARK stick parity I expected to get a parity error.

But as I was saying this happen only if the data is 0x55, in case the data 0x57 I got no parity error.

[ShengN_Intel]

Hi @Patrik78 ,

Seems like there's no problem with the data package and LCR. Then it's better to issue a Break Interrupt (bi) between the received data packages by holding serial input, sin, in a logic '0' state for longer than the sum of start time + data bits + parity + stop bits and after that logic '1'. Because as mentioned in document that the Parity Error (PE) bit (LSR[2]) will be set if a break interrupt has occurred, as indicated by Break Interrupt (BI) bit (LSR[4]).

Let me know if you have any further update.

Thanks,

Best regards,

Sheng

p/s: If any answer from the community or Intel Support are helpful, please feel free to give best answer or rate 4/5 survey.

[Patrik78]

Hello Sheng,

we can't use break signal in our application, so we're forced to make the parity check work without the use of break.

Could you check other reasons why the PE is set receiving 0x55 with '0' as parity bit, and not set when receiving 0x57 with '0' as parity bit , assuming receiver is set to check parity MARK?

[ShengN_Intel]

Hi @Patrik78 ,

[Edited]

Seems like the result shows that you're using 'odd parity' for parity selection. Have you using the correct LCR?

Thanks,

Best regards,

Sheng

[ShengN_Intel]

Hi @Patrik78 ,

I further found out this KDB link https://www.intel.com/content/www/us/en/support/programmable/articles/000073704.html

Probably suits your problem. Are you using the Altera Arria® 5 and Cyclone® V SoC UART?

Thanks,

Best regards,

Sheng

p/s: If any answer from the community or Intel Support are helpful, please feel free to give best answer or rate 4/5 survey.

[ctavoni]

Hello Sheng,

sorry but I can not understand why is so difficult to have a clear answer on 16550 IP.

We want to know if the Stick Parity function implemented in the 16550 IP works as the Mark-Space parity in other standard Uarts.

In practice Sticky Parity is simply when the parity bit is always transmitted and checked as a '1' or '0' independently from other the data bits or other UART functionalities

Do it works on 16550 IP?

Best regards

Claudio

[ShengN_Intel]

Hi @Patrik78 ,

Thanks for all the details provided. Let me further consult opinion from internal engineering team and get back to you soon.

Thanks,

Best Regards,

Sheng

[ShengN_Intel]

Hi @Patrik78 ,

Expert feedback:

Example flow for data transmitted (assuming stick parity not enabled):

Data	Even Parity (Tx)	Even Parity (Rx)
0x55	0101 0101 + 0 (check bit ‘0;’ because even par)	0101 0101 + 0 (checked bit ‘0’)
0x57	01010111 + 1 (check bit ‘1;’ because even par)	01010111 + 1 (checked bit ‘1’)

Data	Odd Parity (Tx)	Odd Parity (Rx)
0x55	01010101 + 1 (plus bit ‘1;’ because odd par)	01010101 + 1 (checked bit ‘1’)
0x57	01010111 + 0 (plus bit ‘0;’ because odd par)	01010111 + 0 (checked bit ‘0’)

(Since Stick parity is enable, parity does not depend on data):

Data	Even Parity (Tx) (SP=1, EPS=1, PEN=1)	Odd Parity (Rx) (SP=1, EPS=0, PEN=1)	Error
0x55	01010101 + 0 (plus bit ‘0;’ because even par)	01010101 + 0 (checked bit ‘0’)	Should get an error because Rx data is even parity
0x57	01010111 + 0 (plus bit ‘0;’ because even par with stick par)	01010111 + 0 (check bit ‘1;’ because even par)	Should not get an error because Rx data is odd parity

***The receiver side it will only check, the parity bit addition will be at the transmitter side only.

Both transmitting and receiving UARTs recommended to be configured same parity, either even or odd.

Recommended not to use the Stick Parity to 1, since the parity bits will be set, it will not be dependent on the data transmitted. 

Thanks,

Best regards,

Sheng

p/s: If any answer from the community or Intel Support are helpful, please feel free to give best answer or rate 4/5 survey.