DS90UH948-Q1: unable to communicate with deserializer

Hi Jack,

Thanks for the response.

We have taken care the timing. Please see below the zoomed version.

We didnt have the implementation of Hard Reset (Toggling of PDB) when this image is captured. Hard Reset was implemented later.

The time delay between PDB High to start of I2C is around 10ms.

Is there anything else we need to check?

Thank you.

Regards,

Viswanath

Hi Viswanath,

Could you attach the logic pro file so I can look at the I2C bus and the power rail startup sequence?

Best,

Jack

Hi Jack,

I have Salea logic analyzer file.

Regards,

Viswanath

Attachment

2E_PDB.zip

Hi Viswanath,

Thank you for attaching the logic analyzer file. I saw that there is glitching on the 3.3v and the 1.2v rail although this is most likely due to the I2C lines creating noise.

There are minimum rise requirements for both the 3.3v and 1.2v rails on the 948. Can you confirm that those minimum rise times are followed? Are you using a custom board or a TI EVM?

Also, are you not able to communicate via I2C to the 948 at all or just after startup? It's not clear yet why the 948 is not acknowledging the I2C write.

Best,

Jack

Hi Jack,

I think the minimum rise time requirement is followed. Please find attached the another logic analyzer file.

The delay between 3.3V and 1.2V is around 90ms. Is it fine? 

We are using a custom board.

After power, we are trying to configure the device. Since NAK is received on I2C, I2C driver notifies as the sequence is failed. Since sequence is failed, further commands are not initiated from the software. We have not implemented any retry logic currently.

RiseTime_Measurements.zip

Regards,

Viswanath

Hi Viswanath,

VISWANATH YANAMANDRA said:

The delay between 3.3V and 1.2V is around 90ms. Is it fine? 

This is fine. 

VISWANATH YANAMANDRA said:

Since sequence is failed, further commands are not initiated from the software. We have not implemented any retry logic currently.

I wouldn't expect to see a difference with more I2C commands. The other reason the device could be sending NACKs is because the device is strapped to the wrong address. Could you try some of the different addresses to check?

VISWANATH YANAMANDRA said:

We are using a custom board.

What MCU is used? And has remote communication been successful by using remote writes on the serializer? If you have the serializer on hand, does it lock to the deserializer when using video input?

Best,

Jack

Hi Jack,

We are using Infineon Traveo II. We will check with different address and post the status.

We don't have serializer at the moment. We are trying to get one kit.

is there any dependency with serializer? Our understanding is deserializer works without serializer as well.

is there anything else we can check? 

Regards,

Viswanath

Hi Viswanath,

VISWANATH YANAMANDRA said:

is there any dependency with serializer? Our understanding is deserializer works without serializer as well.

I2C communication will work without the serializer. I want to see if the remote I2C communication is functional to see if the issue lies in the local I2C bus or the internal I2C logic.

VISWANATH YANAMANDRA said:

is there anything else we can check? 

Try adding a couple more I2C commands to make sure the NACK is occurring repeatedly. If the 948 keeps NACKing, then the address is most likely incorrect.

Best,

Jack

Hi Jack,

We have connected external I2C tool, disabled the I2C transactions from MCU and tried pinging the device with different addresses (7 bit range). Unfortunately, received NAK for all address.

We will check in multiple boards and see of the problem is observed in all boards or not.

Regards,

Viswanath

Hi Viswanath,

Thank you for the update. Below is an I2C transaction I measured on a 948 EVM.

Let me know if you observe the same NACK behavior on the other boards.

Best,

Jack

Hi Jack,

What would be the configuration of INTB_IN and BISTEN pins?

on our board, both are connected to MCU and in software

INTB_IN is configured as output (input to serializer)

BISTEN is configured as input (output from serializer)

does this impact deserializer?

Regards,

Viswanath

Hi Viswanath,

INTB_IN and BISTEN will not impact local I2C communication to the deserializer. Both INTB_IN and BISTEN are inputs on the 948. 

Best,

Jack

Hi Viswanath,

Could you send over the schematic for the board? You can send it in this thread, by private message, or to my e-mail. Because this is a custom board and not a TI EVM, I want to make sure there are no system level issues.

Best,

Jack

Hi Jack,

Could you please share your mail id?

Thanks and Regards,

Viswanath

Hi Viswanath,

My email is j-scherlag@ti.com

For future threads, you find emails by clicking on our profile and clicking on "myTI Information".

Best,

Jack