UCD3138064: a question about the register of DATA_READY in I2C module.

First of all, thank you for your reply! The goal of my project is to enable the host computer to control the UCD3138064 through the PMBUS for power management. At the same time, I also need to let UCD3138064 get the temperature of the temperature sensors through IIC communication. Is this UCD3138064 capable? Is there anything I need to pay attention to? When I debugged, I found that when I read I2CRegs.I2CST.bit.MASTER, I switched between 0 and 1, instead of being in host mode (UCD3138064 is configured in host mode for host mode, in IIC communication).

Looking forward to your reply!

Thank you for your information! However, I want UCD3138064 as the host. UCD3138064 is configured to accept 2 bytes of data after sending a read command to the slave. My doubt is, can I use the DATA_READY flag to determine whether the read is successful, instead of the EOM flag? Because, I need to judge whether the current slave is damaged. If the slave is damaged, I need to handle the fault. If only the EOM flag is used, how can I judge whether the slave is normal? When I debug, I use the host computer to check that RD_BYTE_COUNT in UCD3138064 is 0, but there is data change in I2CRXBUF. Why is this? The IIC related code is as follows:

void init_i2c(void)
{
/*********I2C Initialization********************/
 //Configure FAULT0 and FAULT 1 pins for I2C
 //Fault 0 is used for I2C clock, and Fault 1 is used for I2C data
     MiscAnalogRegs.IOMUX.bit.FAULT_01_MUX_SEL = 2;

 //Enable master mode and I2C mode.
    I2CRegs.I2CCTRL3.bit.MASTER_EN = 1;
    I2CRegs.I2CCTRL3.bit.I2C_MODE_EN = 1;

//Since the I2C interface is derived from a PMBus interface, the Clock Low Timeout function should be
//disabled for full I2C emulation:
     I2CRegs.I2CCTRL3.bit.CLK_LO_DIS = 1;
     I2CRegs.I2CINTM.bit.EOM = 0; // interrupt is enabled at the I2C:
}

void i2c_read()
{
      Uint32 high_byte,low_byte;

      if((CimRegs.INTREQ.bit.INTREQ_DIGI_COMP == 1))    //if i2c eom interrupt is being requested
     {
            if(I2CRegs.I2CST.bit.NACK == 0) //if we were acked, it's done
            {
                received_buffer = I2CRegs.I2CRXBUF.all;

              high_byte = (received_buffer&(0x0ff));
              low_byte = ((received_buffer&(0xc000))>>14);
              temperature_buffer = (high_byte<<2)+low_byte;
            }
       }  
}

In addition, by looking at the UCD3138064 Enhancements Programmer’s Manual, the I2C_MODE_EN of the I2C Control Register 3 is set to 0 by default, but when I set it to 1, will PMBUS be affected? As shown below,

OK, now I'm really confused about what your question is.  I assume that you are using the PMBus interface for the communication between the UCD and the master, and you are using the I2C interface for the communication between the UCD and the temperature sensor?  If not, please let me know.

If my assumption is correct, then I can say that there is no connection between the I2C interface and the separate PMBus interface.  Just as a note, the I2C interface on the 064A doesn't do slave mode at all.  So you definitely want to set the master bit.  

I've already described what sets the data ready in the slave mode.  I haven't looked at master mode, but I expect it is similar, except the master is controlling more.  

I have no idea about why things are changing in I2CRXBUF.  If there's no EOM, maybe the hardware is collecting data, but doesn't feel the need to send it yet, because there's not an EOM yet.  A scope shot of what is happening on the PMBus when this happens would be very helpful.  

What do you mean by the temperature sensor is normal?  If it's not ACKing, I would expect the NACK bit to be set.  If it's ACKing, but stretching the clock, then I'd expect the CLK_LOW_TIMEOUT bit to be set in I2CST.  The clock low timeout doesn't get set until the clock is stretched for 35 msec.

Does everything work OK if the temperature sensor is working correctly?  If so, please send a scope shot of the whole message sequence for that as well.