SN75DP159: Unable to get Reference Clock after programming as per the DP159 as Retimer document

Hi Fadil,

1) 2) page 0, register 0x09[5] -> x-mode enable
3) Following the power-up timing sequence in datasheet's section 9.3.2 should be enough
4) all registers should read the same written value
5) write_csr is a normal I2C function, you can see the I2C behavior on datasheet's section 9.5.2

Regards

I am writing the registers in the sequence mentioned in the document with the exact same values via I2C. Neither I am getting any clock on the AUX pins nor able to obtain the same written values by performing an I2C read operation. The read values differ by the reserved bits which always read 0. If only writing 0x9[5] to 1, X mode is enabled, then the same register configuration sequence should generate clock on the AUX, correct?
The following are the current issues I am facing:
1) No clock on AUX
2) Read values not same as the written values
After performing the register configuration sequence mentioned in the document

Hello Moises, 

I have attached some observation in the attached document. By doing only the configuration in struct DP159InitT RBR_HBR_HBR2_Common_Init[], Section 4, Retimer datasheet, I was not able to get any clock on the AUX pins. But when registers, with reference to retimer datasheet section 4.5, were written, clock-like pulses were obtained the capture of which is also attached. In the document, I have

1) Provided the configuration details to perform the X-Mode Configuration. 

2) Highlighted the registers which do not read back the same value that was written. 

3) Attached the clock that was obtained after configuring both DP159InitT RBR_HBR_HBR2_Common_Init[], Section 4 and Section 4.5, but the clock is not clean. Would it suffice for DP RX?

Obs_Ref.pdf

Hi Fadil,

I see you try to write 0x40 to register 0x00 from page 1, why are you doing this?

remember when you set a single bit, the other bits have to remain unchanged, first read the register, then make an OR to set a bit, finally write the register.

LOCK_COMPLETE is a status bit, you don't have to write it.

The onfiguration in section 4 doesn't need extra configuration from section 4.5, it should output a clock only with the sample scripts.

Regards

Hello Moises,

   I did not know the Page 1, 0x00[4] is a status bit. I was just following exactly that was mentioned in section 4.5. 

   I understood how you are expecting me to write the register values after reading and then writing the values from the sample script. Even after doing this, I am not able to get any clock on the AUX pins. But then again, when I write the configuration excluding the 0x00[4] write, I am getting clock, but its not stable and looking like PWM signal.

   Could you please share some more troubleshooting steps so that I can atleast get the clock from DP159?

   Also, what about the address 0xE which shows different read and write values?

Hi Fadil,

You don't have to add extra procedures for section 4.5, what is described there is already set in the sample scripts, please remove the sequence for section 4.5, the device should work with the sample scripts without adding extra configuration

The AUX_CFG bit (Page 0 offset 0Dh bit 7) must be set to a 1’b1.

{0x0D, 0x80} , //Enable clock on AUX. Select 1/20 mode.

The AUX_BRG_EN bit (Page 0 offset 0Ah bit 3) must be set to a 1’b1.

{0x0A,0x7B} , //Disable HPD_SNK pass thru to HPD_SRC.

LOCK_COMPLETE bit (Page 1 offset 00h bit 6) must be set to a 1’b1.

u16 lock_wait = 256; //Approx 300us with 400KHz I2C.

ReadBuffer[0] = 0;

while (ReadBuffer[0] == 0 && lock_cnt < lock_wait) {

 read_csr  (0x00);

 ReadBuffer[0] = ReadBuffer[0] & 0x40; // 0x80;

 lock_cnt++;

}

TX Lane 0 must be enabled (Page 1 offset 10h bit 0 is 1’b1 and Page 1 offset 10h bit 4 is 1’b0.

Hello Moises,

 I have tried configuring as per your instructions taking references from the Retimer datasheet as well. But still I am not able to get the clock on AUX_P/N pins.

Detailed system setup and my observations are provided in the document. Kindly go through it and suggest if I am missing anything.

System Setup.pdf

Hi Fadil,

Allow us a couple days to review this issue

Regards

Hi Fadil,

Per section 4.3.2 of slla358, I would not expect the TX lanes to be enabled or the pll register to be set until the LOCK_COMPLETE bit is set. Can you move the writes to Page 1, register 0x10 and 0x00 after the LOCK_COMPLETE bit is set? It looks like the clock isn't coming out on AUX because the PLL isn't locked properly.

Regards,
JMMN

Hello JMMN,

   The point you have raised was ambiguous to us as well because we are referring to Xilinx PG064 document guide, the page of which I have attached. In this document, 0x00 & 0x10 of Page 1 are written prior to PLL lock which could be giving us the value of 0xE3 (PLL_CLOCK, LOCK_COMPLETE) bits to be set overriding the proper PLL lock. However, Xilinx also has an implemented software application for DPRX, Xapp1178(open source), in which they are writing 0x00 & 0x10 of Page 1 after getting the LOCK_COMPLETE bit to be set. I shall redo the pointer you have made and record the observation.

   Also, I need clarifications for the following:

1. For the Clock Recovery phase of Link Training of Display Port that depends on Voltage Swing, is the hardware performing recovering on the 10.2 symbols on the main link data lanes? Or it depends on the clock provided say 135Mhz. My understanding is it performs the recovery based on the symbols coming on the main link and doesn't depend on the 135Mhz clock expected from Retimer.

2. For the channel equalization phase of Link Training of Display Port, there are three statuses to be achieved which are Channel_Equalization, Lane_Alignment & Symbol_Lock which depends on the pre-emphasis level. Does the hardware perform the Symbol_Lock latching based upon the clock recovered from the main link ( assumption ) or the clock expected from the retimer?

 

Hi Fadil,

Since the hardware functions you need clarification on are part of the Xilinx design, not the TI part, Xilinx would have to comment on the exact device behavior. That said, I agree that your assumptions make sense:

1. I would expect the clock recovery to occur on the main link data lanes per the specification.
2. Also, I would expect symbol lock to be latched based on the recovered clock.

Regards,
JMMN

Hi Fadil,

Please let us know if there are any further updates on this issue.

Regards,
JMMN

Hello JMMN,

  Thank you so much for following up.

   Currently, we have given the board for replacing the IC. I am not sure how many days it will take for the board to reach back to us. Once we start the debug process, I shall update you with the observations.

HI Fadil,

I will be closing this thread for now, you can repost to it to open it once you get more data.

Regards,
JMMN

hi，

    I have also encountered the same problem，How do you fix it?

  thanks！！！