Nios® V/II Embedded Design Suite (EDS)
Support for Embedded Development Tools, Processors (SoCs and Nios® V/II processor), Embedded Development Suites (EDSs), Boot and Configuration, Operating Systems, C and C++
12589 Discussions

UART 16550 IP - Stick parity problem

Patrik78
Beginner
2,114 Views

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.

0 Kudos
17 Replies
ShengN_Intel
Employee
2,077 Views

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):

ShengN_Intel_0-1669112309644.png

 

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.

 

0 Kudos
Patrik78
Beginner
2,067 Views

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?

 

 

0 Kudos
ShengN_Intel
Employee
2,056 Views

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.


0 Kudos
Patrik78
Beginner
2,042 Views

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?

0 Kudos
ShengN_Intel
Employee
2,028 Views

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.


0 Kudos
Patrik78
Beginner
2,012 Views

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?

0 Kudos
ShengN_Intel
Employee
2,002 Views

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.


0 Kudos
Patrik78
Beginner
1,970 Views

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 ?

 

 

 

0 Kudos
ShengN_Intel
Employee
1,950 Views

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?


0 Kudos
Patrik78
Beginner
1,944 Views

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.

0 Kudos
ShengN_Intel
Employee
1,902 Views

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.

 

0 Kudos
Patrik78
Beginner
1,892 Views

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?

0 Kudos
ShengN_Intel
Employee
1,890 Views

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

 

0 Kudos
ShengN_Intel
Employee
1,871 Views

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.

 

0 Kudos
ctavoni
Beginner
1,848 Views

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

 

0 Kudos
ShengN_Intel
Employee
1,779 Views

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

 

0 Kudos
ShengN_Intel
Employee
1,689 Views

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.

 

0 Kudos
Reply