• State TI Thinks Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 2 answers
  • Subscribers 21 subscribers
  • Views 621 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

CDCE925: CDCE925 configuration failed

Darren Yang
Expert 2000 points
Part Number: CDCE925
Other Parts Discussed in Thread: PCA9306

Hi Sir

1. The specific application of CDCE925 is as follows: the clock source is 148.5M active crystal oscillator, but the PLL goes straight out of 148.5M for FPGA; PLL1 out 24M, PLL2 output 156.6M

2. we check the power ripple noise is normal, however, we find motherboard CDCE925 chip configuration failed

a. When I2C operates the 925 chip, reading the chip ID fails;

b. When the first read chip ID is correct, the CDCE925 is directly unresponsive after being written back to the register.

so could you help check it and give some suggestions how to debug it,tks!

  • 0
    Expert 2000 points

    Hi Sir

    any feedback？pls help check it,tks!

  • 0 in reply to Darren Yang
    TI__Genius 16845 points

    First, we need to confirm that the I2C write operation is working. Are you writing to the correct I2C address? Do you observe an ACK on SDA? Is it possible that the I2C address overwritten? 

    I2C address is given in Table 5. As you can see in table note 1, the address bits A0 and A1 are programmable by writing to register 01 bit [1:0]. This means there are four possible I2C addresses, if it was rewritten. You might confirm that the device is not responding to any of these addresses.

    Are you using the EVM and GUI?

    Kind regards,
    Lane 

  • 0 in reply to Lane Boyd
    Expert 2000 points

    Hi Lane

    1.This is a problem with the batch board, and now it is a 10% failure rate. After replacing the 925 chip, there is no problem with the initial I2C device address error.

    2. The case where the I2C device address is overwritten does not exist because there are currently two operations that do not overwrite the I2C device address: one is direct write, A0 and A1 of register 1 are always 0; the other is read first. The register value is modified and then written, such as register 1, only the INCLK bit is modified.

    3.When the above register is directly written, the register value comes from the GUI generated.

    4. Regarding the ACK problem, the ACK can be read normally, and the ACK can not be obtained when the reading is not normal.

    5. we also need you help to check the above doubt is that If the EELOCK bit in Register 1 is written 1, can the register not be written, not just the EEPROM locked?

  • 0 in reply to Darren Yang
    TI__Genius 16845 points

    Thanks for the information.

    I wonder what is causing the devices to fail. The successful AB swap indicates the possibility that some of the devices are somehow damaged.

    You are using the GUI to generate your register values, but you are not using the GUI to program the part, correct?

    Setting EELOCK will permanently lock the EEPROM, but will not prevent the registers from being written.

    Kind regards,
    Lane

  • 0 in reply to Lane Boyd
    Prodigy 10 points

    Hi Lane

    the  register values is collect, now we not know what reason causing the devices to fail, so we need you help,tks!

  • 0 in reply to user1470612
    TI__Genius 16845 points

    I suspect the failing devices have been damaged. Do you still observe functionality?

    Do you measure continuity between VDD and GND? Or, abnormal operating current'? What are other failure symptoms of CDCE925? 

    Are all devices from the same lot?

    I could also support a schematic review.

    Kind regards,
    Lane

  • 0 in reply to Lane Boyd
    Expert 2000 points

    Hi Lane

    The schematic is shown in the attachment. Is the VDD vs. GND waveform fingerprint noise? If it is, 3V3 and 1V8, the measured ripple noise is not higher than 25mV (test conditions: 1:1 probe, 100M bandwidth oscilloscope, spring shortest ground test). The obvious feature of the abnormal IC is that the ID read returns 0xFF.SCHEMATIC1 29 CLOCK.pdf

  • 0 in reply to Darren Yang
    TI__Genius 16845 points

    Readback of 0xFF does not provide us much information about the potential cause of the failure unfortunately.

    One thing to check is the I2C connection. CDCE925 has a 1.8V core. There are no external I2C pullups shown in the schematic, I assume there are none present on the bus. If there are external I2C pullups, make sure the I2C lines are pulled to 1.8V.

    If the host is driving 3.3V levels, you may need to use an I2C level shifter to translate from 3.3V to 1.8V. For example, CDCE925EVM uses PCA9306.

    Kind regards,
    Lane