• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 22 subscribers
  • Views 490 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CDCE913 unable to read ,,,

Richard Gammage
Prodigy 70 points

Hello

I mistakenly thought that lock EELOCK was the command to write the device ... and it is possible that is what I have done ...... is there any way to check?

Current all I get is 0xff for byte count and all registers upon any read ... If I have locked the EE is this what I should expect?

It is frustrating to realise you can get exactly what you want from a chip and then not be able to get it to fix the results ...

Regards

Richard

  • 0
    TI__Mastermind 32575 points

    Hi Richard,

    From the datasheet:

    "If this bit (EELOCK) is set to high in the EEPROM, the actual data in the EEPROM is permanently locked. No further programming is possible.

    Data, however can still be written via SDA/SCL bus to the internal register to change device function on the fly. But new data can no longer be saved to the EEPROM. EELOCK is effective only, if written into the EEPROM."

    Are you able to write different data to the registers via I2C to change the configuration and read-back the same data? 

    If you mistakenly wrote EELOCK in the EEPROM, could you just replace the chip with an un-programmed device and start over? 

    Regards,
    Alan 

  • 0 in reply to Alan O
    Prodigy 70 points

    Hello Alan

    I have moved on slightly from this position .... initially all reads were giving me 0xFF and I wondered whether the EELOCK was causing the device to be unreadable to stop copying etc., like processor chips do .... but my problem is slightly different. I proved last night that I can read this chip repeatedly until I write to it ..... then I cannot read data again I get 0xFFs. Also as this chip has yet to be written to, the initial/factory state of BCOUNT is 7, no wonder another correspondent to this forum has had problems ...... I am using a repeated 'byte read' as I could not get 'block read' to work ..... I wonder whether this is the same issue i.e. a problem with the counters.

    I can only assume at this point that the chip thinks that the write is not complete, either I have tried to send too many. or too few bytes of data ..... but the chip outputs change as the code expects ... will a I2C 're-start' kick it back into life?

    I will also try  32 x byte write ..... as 32 x byte read works ..... the only difference is the counter

    There seems to me to be a trick to programming this beasty which is not documented ......

    Regards

    Richard

  • 0 in reply to Richard Gammage
    Prodigy 70 points

    Hello Alan ....

    I now understand this device enough to get it programmed ...... and answer other's questions too ...

    First I could not get ANY block command to work properly, but maybe now .... see below.

    The correspondent who could only read 7 bytes ... that is the way they are shipped, byte 6 = 0x0e, SB 0x40!

    I write the PLL data a byte at a time, after waiting for 200mS for my linear power supply to settle(?)

    I add a delay of 500uS between each byte.

    Then the control bytes from 2 - 6 with delay as above .... writing to b0 and 1 seems to cause problems.

    I then wait 10 seconds ...... write 0x40 to b6 ..... wait another 200mS write 0x41 to b6 ..... wait another 200mS write 200mS to b6 ....... and the device is programmed.

    I do not claim that any of these delays is optimum but after weeks of trying to program these devices I am content to stop here. I do hope this information is of help to others.

    Regards

    Richard