• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 21 subscribers
  • Views 616 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.

CDCE925 Technical Request- datasheet

Alesea
Prodigy 225 points
Other Parts Discussed in Thread: CDCE925

Hi,
Can you please help my customer?
Here is the original request:

***
I have designed in your CDCE925 in a new product, and am about to start programming it.

CDCE925 datasheet pages 13-14 I2C communication are confusing.

On Figure 11 it looks like Byte Count N is sent from slave to master. It is my belief that the master should instruct the slave (i.e. CDCE925) how many bytes the master wishes to read. On the datasheet it looks like the opposite is the case.

Instinctively, I'd assume the master has to sends the Byte Count after the Command Code, before the Repeated Start and Slave Address. But I could be wrong. This part being new to me I don't wish to spend a lot of time experimenting like this.

Also, the "A" for ack is not specified as 0 or 1 in the communication. It is my experience with I2C that the last byte transferred is NACKed to indicate it being the last. However, this is not always the case with all implementations.

Please let me know if I should send/expect ACK for all bytes, or if I for certain bytes should send/expect NACK.

I assume the second "S" in "Byte Read Programming Sequence" should rather be denoted as "Sr".

I have seen other documents on CDCE925 (and friends) I2C programming, but I don't know which ones to use as the definite reference when the datasheet is confusing.

Best regards,
****
Thanks in advance!
Alesea

 

  • 0
    TI__Expert 5725 points

     >>In the block read (Figure 11) the Byte Count N is coming from the slave. The byte count is stored in the slave: byte 6, bits 7:1 (page 16 of CDCE925 datasheet).

    Also, the "A" for ack is not specified as 0 or 1 in the communication.

    >>A is acknowledgment, the slave will bring the SDA line low. The slave acknowledges that way that the communication was successful. On the 9th clock pulse, the slave should bring SDA low to acknowledge that the communication was successful. As specified in the images, after each byte send, an acknowledgement from the slave should occur.

    The following application note contains some screenshots on how should this happen.

    http://www.ti.com/lit/an/scaa106/scaa106.pdf

    http://www.ti.com/lit/an/scaa105/scaa105.pdf

     

    The second "S" in "Byte Read Programming Sequence" should be denoted as "Sr". That change will be submitted in the datasheet and updated to the web next week.

     

     

     

  • 0 in reply to mapefer3
    TI__Prodigy 225 points

    Incredibly fast :)
    Thank you very much!
    Alesea

  • 0 in reply to mapefer3
    Intellectual 710 points

    Hi,

     

    Missing out on the multi-byte read sequence and register 0x06 was my bad. When you revise the datasheet, please have Figure 11 refer to register 0x06. That will make it much more user friendly.

     

    In my I2C experience, the last byte in each sequence is NACKed by the receiver after it has been sent by the transmitter. So the ACK is not always 0. In my multi-byte read code, I had to set the MCU to NACK (0b1) the last byte coming from the CDCE925. Otherwise it would hold the I2C bus.

     

    But in the multi-byte write sequence, the CDCE925 seems to send the MCU an ACK where a NACK might be expected. But not all I2C implementations do it.

     

    This is why I ask you to please show when the CDCE925 - as slave-receiver - will send ACK/NACK, and when it - as slave-transmitter - will expect ACK/NACK fromthe MCU.

     

    Best regards,

    Borge

     

  • 0 in reply to Borge Strand-Bergesen
    Intellectual 710 points

    By the way, here are the defaults I read out of the chip using the proper (reg. 0x06) multi-byte read method:

    /* Defaults fetched
    00:07   81 00 B4 01 02 50 0E 0E
    08:0F   00 00 00 00 00 00 00 00
    10:17   00 00 00 00 ED 02 01 01
    18:1F   00 40 02 08 00 40 02 08
    20:27   00 00 00 00 ED 02 01 01
    28:2F   00 40 02 08 00 40 02 08
    */

     

    Borge