Hello team,
We are using DS90UH948TNKDRQ1 in our program.
After power on, when we try to configure the device, we always receive NAK.
Can anyone help me to understand the reason for NAK?
Thanks for your support in advance.
Regards,
Viswanath
This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Hello team,
We are using DS90UH948TNKDRQ1 in our program.
After power on, when we try to configure the device, we always receive NAK.
Can anyone help me to understand the reason for NAK?
Thanks for your support in advance.
Regards,
Viswanath
Hi Viswanath,
Thank you for providing your system schematic and the logic screenshot. Based on your screenshots, it looks like the I2C command is happening before PDB is pulled high. Section 9.1 in the datasheet covers the recommended power-up sequence and there is a minimum time from when PDB is pulled high to when I2C is ready. After PDB is pulled high, a minimum of 2ms is needed before any I2C writes/reads.
Best,
Jack
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 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.
Regards,
Viswanath
Hi Viswanath,
The delay between 3.3V and 1.2V is around 90ms. Is it fine?
This is fine.
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?
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,
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.
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 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
Hi Viswanath,
Because this issue has been resolved over email, I am closing this thread.
Best,
Jack