• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 3 answers
  • Subscribers 22 subscribers
  • Views 437 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.

Original question:

CDCEL913: How to config the the CDCEL913 correctly?

CDCEL913: Default Address Bits

Sean Heffernan1
Intellectual 290 points
Part Number: CDCEL913
Other Parts Discussed in Thread: CLOCKPRO, CDCE913, CDCE925

I would just like to confirm that the default Slave Address of the CDCEL913 is 1100101b.

I know that address bits A1 and A0 are programmable, and the Configuration Register Map indicates that the default setting for these bits is 01b. But the datasheet also says that if VDDOUT is forced to GND, the two control pins (S1 and S2) temporarily act as serial programming pins (SDA/SCL) and the two slave receiver address bits are reset to A0 = 0 and A1 = 0. Also, when using the Bit Viewer of the ClockPro software, Register 01h displays a value of 00h; so is there an error in the datasheet and the default Slave Address is actually 1100100b, or is the ClockPro software reconfiguring the address bits to a non-default value? If it's the latter and I preprogram my devices using ClockPro (and don't change the SLAVE_ADR value beforehand, does that mean that I will need to use Slave Address 1100100b for future in-system I2C accesses?

  • 0
    TI__Mastermind 18070 points

    Hi Sean,

    My coworker will get back to you within 24 hours.

    Regards,
    Hao

  • 0
    TI__Genius 9935 points

    Hello Sean,

    Yes, as shown in the Datasheet, CDCE913 and CDCEL913 addresses are defaulted to 1100101b.

    If you have forced VDDout to GND the address bits will then have changed to A0 = 0 and A1 = 0. This address will be kept until reprogrammed and the ClockPro software should be reading back from the device connected properly.

    As stated previously, you might need multiple addresses. To solve this need, I would advise against forcing VDDout to GND for your device's use case as they would all then be changed to 1100100b and require reprogramming to change again.

    Hopefully you found this helpful.

  • 0
    Intellectual 290 points

    Aaron,

    Thank you for confirming that the default address is 1100101b, and that forcing VDDout to GND will "override" this default address. I still need confirmation regarding the ClockPro settings, however; when preprogramming my CDCEL913 devices, it LOOKS like ClockPro will change the default address to 1100100b unless I manually override SLAVE_ADR register value. So if I DON'T change the SLAVE_ADR register value before programming my devices, does that mean that I need to use address 1100100b if wish to reprogram the devices in-system?

  • 0 in reply to Sean Heffernan1
    TI__Genius 9935 points

    Hello Sean,

    The default programmed address for the CDCE(L)913 devices is 1100101b, the only ways to change this address is:

    1. VDDout is forced to GND - address will change to 1100100b.

    2. Register 01h [1:0] SLAVE_ADR bits value is reprogrammed.

    If you want to say that 1100100b is a 'default' of your system you could, this would simply require VDDout to be forced to GND. Please note that if multiple devices are used at once I would advise to change to 'default' individually and then reprogram address bits. i.e. 4 devices factory defaulted to 1100101b changing device 1 to 1100100b, reprogramming to 1100111b, second device 1100100b then 1100110b, etc.

    Hopefully this helps.

  • 0 in reply to Aaron Black
    Intellectual 290 points

    Option 2 is what I am questioning.

    I am creating a setup with ClockPro to configure my input and output frequencies, enable outputs, etc. I don't wish to change the default address, but when I use the Bit Viewer window of ClockPro, it is showing a SLAVE_ADR value of 00b. So when I program my CDCEL913 devices, I am questioning whether or not the slave address is being reprogrammed to 1100100b due to a "glitch" in the ClockPro user interface that THINKS I wish to change the SLAVE_ADR setting.

    As long as I preprogram the devices and then never try to communicate in-system via I2C, the Slave Address doesn't matter. But if I ever need to change some registers in-system, it would hep to know if the address has been reprogrammed by ClockPro. I could just experiment with some programmed boards and see which address the devices Acknowledge, but it would save me some time if you could explain the SLAVE_ADR setting in ClockPro.

  • 0 in reply to Sean Heffernan1
    TI__Genius 9935 points

    Hey Sean,

    The SLAVE_ADR setting in ClockPro is manipulated by the Direct Reg. tab through 'Slave Address' being set from 0 to 3. This would result in the SLAVE_ADR bits in the Bit Viewer window to update accordingly [0,0] to [1,1]. This makes it possible to scan a single communication line for a device and communicate with this device independent of other devices on the line.

    I checked on my own devices through ClockPro between a CDCE925 (default address 1100100b) and CDCE913 (default address 1100101b) and was able to see the address from CDCE913 coming in ClockPro as 1100101b and through the Direct Reg. tab I could change the 'Slave Address' from 0 to 3 - resulting in the SLAVE_ADR bits in the Bit Viewer window to update accordingly.

    I'm thinking that if you are seeing an address of 1100100b on a CDCE913 device this was either previously mistakenly forcing VDDout to GND or you've preprogrammed the device.

    In response to your last statement; yes, if you do not need communication to 4 separate devices at a given time through a single communication point then Slave Address does not matter. Although, if communication was needed through these devices then preprogram these devices, making sure not to force VDDout to GND, and they will be able to communicate individually.

    Hopefully this helps clarify any apprehension.