The TI E2E™ design support forums will undergo maintenance from July 11 to July 13. If you need design support during this time, open a new support request with our customer support center.

  • State TI Thinks Resolved
  • Locked Locked
  • Replies 11 replies
  • Answers 1 answer
  • Subscribers 21 subscribers
  • Views 693 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.

CDCI6214: CDCI6214's waveform is is extremely unstable.

Jimmy Lai
Expert 6845 points
Part Number: CDCI6214
Other Parts Discussed in Thread: USB2ANY

Dear Team,

This 6214 clock configuration, we still feel that there is a problem, the following 125M output waveform, the waveform is

is extremely unstable.

We have ruled out the oscilloscope probe, grounding, measurement method, etc.; the power supply of the clock chip is also OK; the clock trace reference is also fine.

Please help to analyze the reason, whether there is something wrong with it, by the way, our clock power supply is 3.3V, thank you!

Many Thanks,

Jimmy

  • 0
    TI__Mastermind 18070 points

    Hi Jimmy,

    Sorry for the delay. What's the setup difference between the first and second plot? Can you try AC coupling the output? Please show me the output termination and how the waveform is probed.

    Regards,
    Hao

  • 0 in reply to Hao Z
    TI__Expert 6845 points

    Hi Hao,

    It's okay! Thanks a lot!

    The problem of clock drift is caused by the noise on the 220V side of the AC power supply. Connect the 220V ground to the device chassis, or replace another power supply with a lower power, and the clock will not float.

    Now we have two questions to ask, thank you!
    1. In the clock file we generated, we found that nvmcrcerr is sometimes not 0. What might be the problem?

    ----- CDCI6214 EEPROM HEX TEXT FILE ------
    Header Info Wed May 11 20:22:04 2022
    nvmbusy 0x0000
    nvmcrcerr 0x0001
    nvm_wr_error 0x0000
    nvm_rd_error 0x0000
    nvmlcrc 0xabcb
    nvmscrc 0x0000
    nvm_rd_addr 0x003f
    nvm_rd_data 0xee02
    nvm_wr_addr 0x003f
    nvm_wr_data 0xabcb

    2. The 25 M clock of Y0 output bypass, can you adjust the edge to be steeper, and adjust it to the same square wave as the active crystal oscillator? We want to send this kind of clock to CPLD for use.

    Many Thanks,

    Jimmy

  • 0 in reply to Jimmy Lai
    TI__Mastermind 18070 points

    Hi Jimmy,

    For the CRC to work, you have to write the correct CRC value to the stored CRC register first, then compare to the live CRC. Please refer to the datasheet for details. This is of course when you use the EEPROM. If you don't use EEPROM then CRC doesn't mean anything.

    There's a slew rate control field here:

    Regards,

    Hao

  • 0 in reply to Hao Z
    TI__Expert 6845 points

    Hi Hao,

    We appreciated your great support always!

    We want to use the burner to solidify the clock chip. How can I export the burn file? All I export now are text files, as shown in the attachment. Thanks!

    Could you guide us how to export file? Thanks!

    ac5_6214_eeprom_20220525.hxt and

    AC5_6214_HexRegisterValues_20220525.txt 
    R70	0x00460000
R69	0x00450000
R68	0x00440000
R67	0x00430020
R66	0x00420200
R65	0x00410F34
R64	0x0040000D
R63	0x003F4210
R62	0x003E4209
R61	0x003D1500
R60	0x003C0018
R59	0x003B1023
R58	0x003A0008
R57	0x00398851
R56	0x00380405
R55	0x00370005
R54	0x00360000
R53	0x00358000
R52	0x00340008
R51	0x00338861
R50	0x00320425
R49	0x00310005
R48	0x00300000
R47	0x002F8000
R46	0x002E0008
R45	0x002D0851
R44	0x002C0405
R43	0x002B0005
R42	0x002A0000
R41	0x00298000
R40	0x00280008
R39	0x00270851
R38	0x00260401
R37	0x00250004
R36	0x00240000
R35	0x00238000
R34	0x00220050
R33	0x00210007
R32	0x00200000
R31	0x001F1E72
R30	0x001E5140
R29	0x001D4014
R28	0x001C0000
R27	0x001B0401
R26	0x001A0A1C
R25	0x00192406
R24	0x00180601
R23	0x00170505
R22	0x00160000
R21	0x00150000
R20	0x00140001
R19	0x00130000
R18	0x00125500
R17	0x001126C4
R16	0x0010921F
R15	0x000FA037
R14	0x000E9FC3
R13	0x000D003F
R12	0x000C9FC3
R11	0x000B003F
R10	0x000A9FC3
R9	0x00099FC3
R8	0x00080001
R7	0x00070C0D
R6	0x000610EC
R5	0x00050028
R4	0x00040055
R3	0x00030800
R2	0x00020053
R1	0x00016A65
R0	0x00003000
     

    Many Thanks,

    Jimmy

  • 0 in reply to Jimmy Lai
    TI__Mastermind 18070 points

    Hi Jimmy,

    The .hxt file that you attached is the right EEPROM image. You can take Byte 0 through Byte 64 from it and write to EEPROM through your own burner if needed. EEPROM programming method is described below:

    Note that it lacks one procedure at the end. You need to relock the EEPROM to 0x0 after programming.

    Regards,
    Hao

  • 0 in reply to Hao Z
    TI__Expert 6845 points

    Hi Hao,

    We appreciated your great support!

    We have a CDCI6214 clock chip working abnormally. After using TICS software to read and write, it is found that the data in the eeprom is not normal. The attachment is the eeprom data read twice. The configuration is: REFSEL=MID, EEPROMSEL=MID , the i2c address is 0x74
    1. 123.hxt is the data read directly after power-on, no data is written. At this time, most of the data of page1 are exactly the same, and the nvmbusy status is -0x001
    2. 789.hxt loads the configuration into the register and then saves the configuration to page0 through the Register Commit method. At this time, the eeprom data is read out. The data of page0 and page1 are all 0x4382, and the nvmbusy state is 0x0001
    3. HexRegisterValues.txt is the register data exported after the above operations
    Do you know what is wrong with the hardware of this CDCI6214? What is the reason for the abnormal operation? We have not done any hardware testing on this CDCI6214. Can you provide us with a recovery method? Thanks!

    123.hxt

    789.hxt

    3731.ac5_6214_eeprom_20220525.hxt

    Many Thanks,

    Jimmy

  • 0 in reply to Jimmy Lai
    TI__Mastermind 18070 points

    Hi Jimmy,

    You should use direct access method to write the EEPROM image.

    Regards,
    Hao

  • 0 in reply to Hao Z
    TI__Expert 6845 points

    Hi Hao,

    Thanks for your great support!

    I have also used the USB2ANY to connect to the computer to test the method on the left, and the same problem occurs, which is consistent with the phenomenon of reading data after writing the data in the method on the right.
    What is the reason?

    Thank you,

    Jimmy

  • 0 in reply to Jimmy Lai
    TI__Mastermind 18070 points

    Hi Jimmy,

    In this case you should probably try another chip. It is not normal that NVMbusy bit is always 1. 

    Regards,
    Hao

  • 0 in reply to Hao Z
    TI__Expert 6845 points

    Hi Hao,

    Thanks for your great support!

    Could you please help to generate programming file(.csv/.xml) for attachment.

    Denverton_Digital_Power_IC_Setup_20210610.tifsp

    Many Thanks,

    Jimmy

  • 0 in reply to Jimmy Lai
    TI__Mastermind 18070 points

    Hi Jimmy,

    I'm not sure what you are looking for and I haven't seen this file format before. Can you elaborate?

    Regards,
    Hao