CDCE913 EEWRITE not functioning

Hello Erik

I have the same issue ...... and will let you know if I get any where! I also suspect that the higher speed synthesizer/oscillator has a problem too .... I can get the chip to work at 80 MHz but not at 160MHz as Clock Pro recommends.

I am trying to program in from a PIC and that is not working down at 1.8v that I see this chip recommends as the pull up on the CLK/DAT lines .... it seems to work at 3.3v .......

Richard.

Hello Erik

My CDCE913 is now working using the 80MHz oscillator. What I found was that while the timing of the I2C looked perfect, the CDCE chip rejected 3 bytes out of 16 when block writing the Synthesizer block 0x10 - 0x1f ..... The digital scope was the clue ,,,,, it decoded what I was sending (which was correct) but some bytes were being being shown as NAKed. I reduced the clock speed from 100kHz to 97.5kHz and all bytes were received OK ....... then followed a time when everything was being NAKed .... at which point I gave up for the evening ...... today it is working as I need it to ......

This does explain why, and how, I have had it working before ... sending individual bytes so timing is less of an issue ..... I hope this helps you too .....

There is much I am unsure of .... but I am not paid to sort out all the issues this device has!

All the best

Richard

The problem isn't writing bytes to the registers of the chip, it's getting those to be written out to the EEPROM.  I've had I2C issues with other chips on the bus, but not with the CDCE.  Anything I write out to the (RAM-based) registers always comes back properly.

So, is anybody from TI actually going to weigh in here, or are these forums not actually how you get support, even though they're the only option presented?

Hello Tim

A couple of things, I have had no errors since dropping to 97.5k .... so I am fine now. I am using the CDCE913 .... and I found tying up the I2C resistors to 1.8v was a bad mistake as nothing worked, reverted to 3v3 ..... The signals did not move so may not be a fault with this chip. I also changed the setting so the clock drops before the data by 300ns ... I did not see any difference but left it this way.

Thanks Richard

Timothy T said:

from your initial post - you mention that the device powers up in a state as if the EEPROM programming was ignored. When using I2C, S1/S2 pins are forced to 0 for EEPROM state selection on power-up. Meaning only the state of S0 matters and only option 0 or 1 is available. Could you be programming a different state than 0 or 1 and therefore getting the same state 0 or 1 as selected by S0?
- Can you attach your programming and advise the state of pin 2 (S0) on your schematic at power-up?

At this point S0 is left floating, but I try to set up my programming so it's the same state on both.  I can tie it to ground in the next version if that's a good idea, but I'm 99% sure it's not the problem.

The reason for that is that I read out all the registers after power-cycling, and they are completely unchanged.

At this point all I want to achieve is have the CDCE keep the PLL in powerdown upon application of VCC, so I can delay it's power-up current draw until later.  As such I'm just writing the core registers with:

{ 0x81, 0x01, 0x00, 0x01, 0x02, 0x50, 0x41 }

Timothy T said:

You mentioned that "EEPIP never changes, and a power-cycle of the chip brings back the same old default configuration." I assume before write, EEPIP is 0 (EEPROM programming is completed). Is it possible the write is being completed before you read again? Therefore it appears EEPIP never change?

It's possible (what is the actual programming time?), but the lack of any change in power-powercycle readback corroborates the lack of a proper write cycle.  EEPIP stays 0 at *all* times no matter what.

Hello Erik,

I understand you only modify the registers 0x01 to 0x06 for test purposes and for your full config you add 0x10 to 0x1F.

Before you set the EEWRITE bit to 1: can you please do a read-back of all registers and share the numbers with me?

Then set EEWRITE bit to 1. Then you may do read-backs of the EEPIP bit to crosscheck if you have waited enough. When it is already at a 0, the write is already done and you can set the EEWRITE to 0 again (footnote 9).

Can you please share a snippet of your schematic? It is surprising to me that the I2C only works with 3.3V. The CDCE913 has 1.8V control pins  and can tolerate 3.3V, it must work with 1.8V.

Do you see a clean communication on a scope with enough setup and hold time of the data beyond the SCL high level at the device pin?

Best regards,

Patrick

Patrick Kammermayer said:

I understand you only modify the registers 0x01 to 0x06 for test purposes and for your full config you add 0x10 to 0x1F.

Actually for my purposes all I need to write to EEPROM is Y1_ST0/ST1 to power down the PLL.  The MCU already flashes all the registers at setup time, I just want the CDCE to hold off powering up the PLL until the supplies have stabilized.

Patrick Kammermayer said:

Before you set the EEWRITE bit to 1: can you please do a read-back of all registers and share the numbers with me?

Already checked that:

Core: 81 05 14 01 02 50 40
PLL1: 00 00 00 00 ed 02 01 01
      00 40 02 08 00 40 02 08

Patrick Kammermayer said:

Then set EEWRITE bit to 1. Then you may do read-backs of the EEPIP bit to crosscheck if you have waited enough. When it is already at a 0, the write is already done and you can set the EEWRITE to 0 again (footnote 9).

Yup, doing that:

Before:
Core: 81 05 14 01 02 50 40
PLL1: 00 00 00 00 ed 02 01 01
      00 40 02 08 00 40 02 08
shutting down PLL
02=00 06=40

After:
Core: 81 05 00 01 02 50 40
PLL1: 00 00 00 00 ed 02 01 01
      00 40 02 08 00 40 02 08
writing EEPROM (06=0x41)
readback 01=05
finalizing write (06=0x40)

The readback should be occurring pretty quickly, but no matter what I never see it come back with EEPIP=1.  At this point if I reset the microcontroller the Before registers show 02=0x00, but as soon as I remove and reapply power I get 02=0x14 again right away.

Patrick Kammermayer said:

Can you please share a snippet of your schematic? It is surprising to me that the I2C only works with 3.3V. The CDCE913 has 1.8V control pins  and can tolerate 3.3V, it must work with 1.8V.

My setup is all 3.3V logic, I think it was the other guy's that was mixed.

Patrick Kammermayer said:

Do you see a clean communication on a scope with enough setup and hold time of the data beyond the SCL high level at the device pin?

The rise times are slow because I initially designed with MCU internal pullups.  My next board rev includes discrete pullups.  However, the waveforms are still valid I2C, and it looks like there's plenty of hold time:

Hello Erik,

after reviewing the data once more I found that there is a small inconsistency.

The PWDN bit =1 is basically the same as the Y1_ST[1:0]= 0b00. This means as you set the actively selected state in the "profile 1" with S0=1 to PLL powerdown, it conflicts with that the current state cannot be saved with powerdown to the EEPROM.

But this should not be an issue for your configuration. You already set the PLL MUX to the "BYPASS" setting which automatically put the PLL into a power saving condition.

Moving Y1_ST1= 0b00 to Y1_ST1= 0b01, should allow that your save to EEPROM is successful. (reg 0x02=0x10)

Best regards,

Patrick