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.

CDCI6214EVM: Operation using external processor

Part Number: CDCI6214EVM
Other Parts Discussed in Thread: CDCI6214

Hello!

We're currently developing w/ the CDCI6214 for our solution. As we'll need to generate a requested frequency "on the fly", we can't use TICS to reprogram, so we need the I2C communications up and running. We are currently attempting to connect the I2C ports (GPIO2 & 3) to an external processor for testing. We're trying to do this with minimal soldering changes to the board, so that if needed we can quickly revert back to a setup that works w/ USB so we can use TICS as a development aid.

Unfortunately the user manual doesn't have a great guide as to the process to do this, and we are currently stuck with the CDCI holding the data line low, so we can't even look and see what's going on. We've performed the I2C disable test indicated in the FAQ (REFSEL = L, EEPROMSEL = H/L, RESETN = H, powercycle and check I2C status) and it did not result in a change, so based on that I don't think it is a EEPROM disable problem. We've also removed the MSP430's I2C communication lines (R165 & R166) so that it doesn't interfere with our master. We've also tried setting the LDO jumper for 1.8V and turning off the switch in case that the MSP430 was messing around with power settings, and that hasn't helped things either. We have another device on the I2C bus we're using to test, so we know that it is configured correctly, and the oscilloscope shows the CDCI is holding the data line firmly low.

Is there some obvious procedure available/that I'm missing to convert the eval kit from running off USB/PC to running of External Power/ external processor via I2C? We haven't removed the regulators from EEPROMEL & others, but we aren't sure they are necessary to remove, and we are trying to minimize the amount of bridges to undo in order to bring the system back to a TICS approved state.

  • You may also want to remove R172 and R189 as well. By I2C disable test, are you referring to this FAQ: "I tried different slave addresses and power cycled the device. Nothing makes the serial interface work! Is the unit broken?"

    What supply voltages are you using?

    Note that if you are using the default EEPROM settings, then I2C interface is disabled on page 0. You will want to use page 1 or fallback mode for I2C communication.

    Kind regards,
    Lane

  • Yes, that is the FAQ question I'm referring to. We figured that if that test passed then we would know that fallback is the issue, and we can proceed from there. However, as that resulted in similar behavior, it's not clear if it is.

    The issue currently with fallback is that we currently have yet to remove the TICS interface to the pins. This is the part in the user manual where it says:

    "The connection to the level-shifter should be disconnected using the solder bridges: R157, R173, R174, R188, and R190. Alternatively, the enable pins of the level-shifters can be tied to the disabled state using: R162, R177, R179, R191, and R193. The shunts of the pin headers are used to tie each pin to VDDREF or to GND."

    So far, these have not been touched, and my assumption here is that this would prevent floating the pins in question. (Or, at the very least, we have tried floating those pins and it didn't fix the issue, and not being able to float seems like a logical reason why.) If we knew fallback was the issue and that this was the only way to proceed, then that's what we'll do, but it seems like a lot to do something pretty basic, and I'm afraid that if we go that route we'll wind up making things worse rather than better. So far there's a lot of "I think but don't know" going on.

    For supply voltages, we are trying to use the 1.8 LDO. We've set the corresponding jumper on the power control in the lower left and set the corresponding switch on S2. If there's something else in this process then I can't find it in the user manual.

    I am aware of the default EEPROM settings (but thank you for verifying!) Just to be safe, we've tried both pages (i.e. set EEPROMSEL high and low) and no change has occurred. Further, we had operation via TICS on I2C immediately before this. I'm not sure how to find out whether TICS uses fallback or assumes a good EEPROM in page 1 or something else. So there was at least 1 good setting, we just need to find it.

    We'll consider removing R172 and R189. Would the SN74AVC2T245RSWR have the possibility to clobber communications as well?

    Thank you very much for your assistance!

  • Additional report: This morning we revered back to the hardware that TICS ran on (so replacing the removed resistors) and TICS resumed working. We also pulled an EEPROM data dump and verified that the first word in each page is 0x8200, which as far as we know means that the mode is set to I2C, so there should be no circumstance where the I2C interface is disabled. So somewhere the MSP430 is holding the line low.

  • When you want to use external I2C controller, do you power the board over J1 or J15? Looks like you can use J1 and short J23, leaving J15 floating. Then, connect your I2C controller to J17 and J21. With R172 or R189 removed, the MSP430 would not be able to hold the device pins low.

    Kind regards,
    Lane

  • We are currently attempting to power J1. We've pulled J23 as well, and so far haven't gotten anywhere.

    For the time being we've just connected using power from the USB connection in parallel with TICS. As long as TICS is open and communicating with the MSP430, it will permit the lines to pull up, which then would allow us to connect with our I2C, and continue development from there. (So far that development has generated even more questions, but that would be beyond the scope of the initial question asked.)

  • Using the default settings with external I2C controller connected would be the most simple approach.

    If you want to keep debugging to get external supply power working, here are some additional questions and things to check:

    When the data lines are held low, is the device actually powered on? Recommend to measure the VDD voltages at C45 or C69.

    If you are not seeing valid supply voltage, it could be due to DUT_PWR_EN_MSP430 signal is not driving the correct LDO enable on S2. In this case, you may need to connect an external supply voltage to the center pin of J24/J25/J26/J27 and set S2 accordingly. Also, make sure to set the jumpers on J16 - J22 

    Kind regards,
    Lane