DS90UB941AS-Q1: I2C ACK never received on serialiser

Hello Alex,

It looks like the pictures did not come through on your above post. Can you please retry posting the pictures?

Thanks,

Casey 

Hello Alex,

Thanks for sending. For the 941AS, which clocking configuration is being used and what is the PCLK frequency? 

- PCLK from DSI clock? 

- PCLK from external REFCLK?

Also which boards are being used for this testing? The TI EVMs or custom HW?

Thanks,

Casey 

Hello Casey,

Below the description of our configuration:

Coaxial link using 1 single port

PCLK from DSI clock

PCLK frequency = 72MHz

We are using our custom hardware.

Best regards,

Alex

Hello Alex,

Can you check to see if the CRC error counter is incrementing during operation when you see this issue? Please check register 0x0A. 

Best Regards,

Casey 

Hello Casey,

We check registers 0x0A and 0x0B, and it doesn't increase during the I2C behaviour.

Best regards,

Alexandre

Hello Alex,

Looking closer at the shots provided it seems like there are some short pulse width glitches happening even in the working case:

I'm wondering what these are and if there are potentially more high frequency glitches which are not getting shown by the logic analyzer. Can you please check this behavior with a high speed oscilloscope to see where these glitches are coming from?

Best Regards,

Casey 

Hello Casey,

The glitch you saw above are due to the bad quality of the logic analyzer.

Below the screenshot with a better and high speed scope :)

The glitch are related to a bus released

Best regards,

Alex

Hello Casey,

Attached a screenshot of the behaviour with an oscilloscope.

I stick the pieces of screens back to make it more readable.

At 150,8ms we observe no actions from the serialiser to get the line after the 8th clock and strech up to the 9th clock.

Attached the schematic:

We already switch F3101 and F3102.

And we connect a coax cable directly at the output of the serialiser to improve the signal integrity.

During the I2C communication we also observe a lot of flickering on the display screen.

Any idea of where to look at for debugging the issue ?

Thanks

Best regards,

Alex

Hi Casey,

We observe some  difference in the 941 registers between 2 of our hardware design:

The first design have a stable I2C communication

The 2nd design experience some random I2C errors as explain above.

Below the dump of the first design registers:

Below the dump with the 2nd design

It seems the register 0x0D should be 25 according to revision ID and the 1st design (according to the datasheet), but it is 35 in the 2nd design.

Furthemore, some registers of the first design were not supposed to have these values, but it work !!!

Does it means the design that is not working have a different version of the IC ?

Thanks,

Best regards,

Alexandre

Below a picture of the chip marking of the 2nd design

Hello Alex,

I see two issues in your schematics which I would recommend fixing first to rule them out as potential issues:

1. AC coupling caps are not correct for coax configuration. The DOUT+ cap should be 100nF and the DOUT- cap should be 47nF. Please see table 188 in the 941AS datasheet. 

2. The MODE_SELx straps are not following the datasheet recommendations for resistive dividers. Especially MODE_SEL1 has a value which is much too close to the minimum strap voltage limit. Please change the resistors to the recommended values to center the MODE_SEL strap targets. 

Earlier in the thread you mentioned that registers 0x0A and 0x0B don't increment when the issue is happening but in the reg dumps provided, these registers are maxed out 0xFF and 0xFF which indicates there are many CRC errors in the link.

I can not compare the reg dump provided to the first rev since it looks like they are taken in completely different system states. Also it looks like the first design was configured for STP while this design is configured for coax.

Based on the registers the link is not operating correctly. There are 0xFFFF CRC errors indicated in register 0x0A and 0x0B. So please fix the AC coupling caps as this could be the source of an issue with the bidirectional control channel. Please see if that resolves the link problems with registers 0x0A and 0x0B. 

Best Regards,

Casey 

Hi Casey,

Thanks for the review, i will update the capacitors and MODE SEL resistors values and give you feedback asap.

But it is strange that these values worked properly with our previous design.

Regarding the first design with the first revision chip, we also notice that the serialiser consider our configuration STP (the voltage value of MODE_SEL were compliant with a coax configuration), although it was a pure coaxial link. Other registers were strange also. But it worked well.

Indeed, the registers 0x0A and 0x0B increment, when we remove the coax cable or during the bootloader.

During my test with the I2C behaviour, i reset it with register 0x04, (0x20 value, then 0x00), and notice that it never increment when we loose the I2C communication.

Best regards,

Alex

Hi Casey,

I change de the AC coupling capacitors on serializer side => NOK

I also change the AC coupling capacitor on deserialiser side (948) with  100nF and 47nF => NOK

I change de MODE_SEL resistor according to datasheet instead of eval kit values => NOK

I still have the 0x0A and 0X0B showing errors after initialisation, then error counter is stable, but we always have some I2C data missing, display flickering and lock lost on deserialiser side.

Any idea ?

Best regards,

Alex

Hey Alex,

Loss of lock indicates an issue with the high speed link still. So I think we need to focus there. What type of cable is being used here? Could you send a picture of the test setup? 

Can you please check the recovered forward channel signal eye diagram at the 948 using the CMLOUT feature?

Best Regards,

Casey 

Hi Casey,

We are using coax cable soldered on our serialiser board, we cut the track after to avoid stub.

As already said, it works very well with our previous design with the same cables.

We did the test you request with a 948 eval board to get the CML OUT signals

Below the picture of the serialiser and the coax soldered on the PCB

The margin analysis with the 948

The eye diagram of the CML OUT

The eye diagram during a lose of LOCK (channel 2)

The CML out signals

Hello Alex,

I would not recommend this type of hand soldered connection for high speed signaling. These signals are highly sensitive to the signal integrity. 

What is the difference between the CLMOUT eye diagrams when it is open vs. closed? What changed?

Best Regards,

Casey 

Hello Casey,

Eye diagram are done in a 1us windows. The closed one is during a lose of lock (channel 2), The other not.

And it looks more like a synchronisation issue, since the margin analysis is good.

Best regards,

Alexandre

Alex,

What do mean by channel 2? I thought this was a single FPD-Link application?

Best Regards,

Casey 

Sorry, i forget to provide the legend of the oscilloscope channel

Channel 2 is the lock pin of the 948 eval board

Channel 3 and 4 (not display) are the CML OUT

Math 1  : is CML OUT_p - CML_OUT_n

Hey Alex,

It looks like something is going on with the forward channel frequency causing loss of lock. Since this clock is derived from the DSI input clock, can you please check the eye diagram of the DSI input clock? Also please make sure to use a persistence much higher than 1us. I would suggest several seconds of persistence in order to see if there is a frequency drift or glitch happening. 

Best Regards,
Casey  

Hi Casey,

I will do the DSI measurement tomorrow at my office with a much higher time.

Strange that it could comes from the DSI, because we also have I2C issues with the internal serialiser clock when using the displays patterns.

Do you have other ideas in case the DSI input clock is good ?

Best regards,

Alex

Hey Alex,

If you are still losing lock with serializer PATGEN using internal clock then I really think the issue is related to the hand soldered high speed connection. For this to work I would suggest using a proper coaxial connector routed on the PCB. 

Best Regards,

Casey 

Hello Case,

Below the eye diagram (several seconds of persistence) of the FPD Link of our 1st board which works well.

Compared to the 2nd design which have flickering, i2c, loss of lock

Also, below the MIPI DSI clock eye diagram.

Now, if i loock at the CML OUT, it appears that the Eye is completely closed after the loss of lock.

Best regards,

Alexandre

Hello Alex,

Since you are saying that the eye is relatively open until the loss of lock where it completely closes, are you able to correlate this event of the eye closing to anything happening at the same time in the system? Large power draw? Programming of some register? Does the DSI clock eye also close during that time? 

Best Regards,

Casey 

Hello Casey,

It has been a while since i am looking for a correlation :)

• -Signal integrity and cable quality => improve the signal integrity for sure, but not correlated with our loss of data and lock with a direct connection
• -Power integrity => i have a 5mVpp max noise on VDD11
• -Radiated immunity => i have isolated others RF components like WIFI which is switch off => no correlation
• -Microcontroller:
  • -MIPI DSI eye always open
  • -I2C communication with an other micro in parallel shows the same issue

Next steps:

• Measure the spectrum of the FPD link and compare with our previous design
• New design to evaluate different configuration, component placement and PCB layout.
• Replace the chip with the revision A0 on the current design

Can we send you the layout and schematic then ?

Best regards,

Alexandre

Hello Alex,

Please feel free to share the schematic and layout for review. 

Thanks,

Casey