P1021-QE Processor's UCC Bit shifting problem in NMSI mode

[amanagantivinod]

Hi All,

I am working on P1021rdb board, we are using NMSI mode for Custom protocol implementation. We are successfully put the UCC in fast protocol with transparent mode and using NMSI configuration.

We are trying Processor's pin level loopback.

As mentioned in the QE-data sheet (page 7-13 and page 7-14) NMSI and Transparent

cdp = 0

ctsp = 0

cds = x ( app specific)

ctss = x (app specific)

We set cdp, ctsp to zero and set ctss = 1.

case-1)

cds = 0, in this case sometimes we are able get the proper data (data received is matched with the data that is sent) in pin level loopback. But sometimes we are observing 1 bit shifting in the received data stream.

case-2)

cds =1, in this case always there is a bit shift and none of the times we received data properly.

We have gone through the datasheet from the timing diagrams mentioned in

6.5 Controlling UCC Timing with the RTS, CTS, and CD Signals

We understand following points

1) All control signals (RTS, CTS, and CD) are asserted on falling edge of the clock

2) Data is sent and received on falling edge of the clock only.

3) if CDS = 0, before receiving data CD must be sampled on raising edge of the clock

In our testing regardless of CTS, CD status data is sent and received. Could you please guide us how we can overcome the 1-bit shifting issue. 

unlike TDM there is no option like clock edge selection configuration for sending receiving data, How usually NMSI mode is configured to avoid these bit shifting issues

Your help is appreciated.

[alexander_yakov]

"Transparent" controller means this controller is transparent to any data encoding, start bits and etc - it simple samples RX data when RX clock is present.

So, if you see bit shifting, this basically means you have one extra clock on RX CLK input (I assume data is shifted by one bit). But in case of loopback mode, when transmitter and receiver are clocked by the same clock, you can not have one extra clock, so this bit shifting actually means incorrect sampling point on RX side. I mean, when you shift out (transmit) and sample (receive) data on the same clock, there may be a bit shifting because receiver tries to samle data which is not already set up on transmitter output. Usually, receiver has setup and hold time requirement for data relatively to its sampling point, whereas transmitter has some output delay to output data after clock edge. Therefore, shifting data out and sampling it on the input on the same clock edge is very difficult. To solve this problem, two opposite edges of the same clock are used for receiver and transmitter. If transmitter transmits on rising edge of clock than receiver samples on falling, and viceversa. For UCC in NMSI mode you can not configure sampling clock edge for receiver, but you can invert clock for transmitter. This is done by TCI bit in GUMR register.

Have a great day,
Alexander

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[amanagantivinod]

Hi Alexander,

Thanks for your reply.

When we configure CTS, CD, and RTS are control signals then internal and

external loopbacks are working fine.

But when we configure CTS, CD and RTS as gpios, facing this bitshift issue

again in external loopback.

Functionality wise what happens exactly internal to UCC block, when CTS,

CD, and RTS are configured as GPIO lines.

On Wed, Jan 20, 2016 at 8:14 PM, alexander.yakovlev <