UART 16550 IP - Stick parity problem

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.

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?

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.

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?

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.

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?

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.

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 ?

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?

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.