AM2431: AM2431 I2C slave configuration

Hi Hong,

Hong Zhang said:

Is there an example that I could refer to for setting up the slave mode properly?

I don't see an example of I2S slave mode in the SDK. Setting aside the ACK, how does the I2C behave in response to the transaction from the external device?

Hong Zhang said:

Should the configuration be different between I2C0 and I2C1? Since I2C0 is open drain and I2C1 is emulated open drain. 

I'm looping in a colleague from the HW apps team to help with the I2C open drain question.

Regards,
Frank

To be more specific, I connected the I2C0_SCL to I2C1_SCL and I2C0_SDA to I2C1_SDA on LP-AM243 Evaluation board to implement an external loopback test to test both the master mode and slave mode functionalities.  

Hi Hong,

Regarding the implementation of the open drain versus emulated open drain, there is no functional difference, as long as the high voltage level on the bus is the same as the digital high voltage of the pin (1.8V or 3.3V, as implemented on the design).

Thanks,
Mike

Hi Hong,

Can you share your example code so I can take a look?

Regards,
Frank

 //todo check out of bound condition
    i2cHandle = gI2cHandle[i2c_num];

    /* Set default transaction parameters */
    I2C_Transaction_init(&i2cTransaction);

    //todo check I2C timeout accuracy in ms
    i2cTransaction.timeout = 1000;

    i2cTransaction.readBuf      = i2c_slave_rx_buf;
    i2cTransaction.readCount    = size;
    i2cTransaction.masterMode   = false;


    status = I2C_transfer(i2cHandle, &i2cTransaction);

Hong,

No, I mean can you share the entire application, not just a code snippet?

Thanks,
Frank

Hello Frank, 

I made some progress on the I2C slave side application. Using an external I2C as master, connected to I2C1 on LP-AM243 board, I2C slave is able to receive data. However, if I do external loopback from I2C1 to I2C0 on the LP-AM243x board, sending data from I2C0, and the I2C1 as slave still could not receive data.  My question is more about the setup issue: given there are two additional devices on I2C0 and a LP filter present, is it feasible to do external loopback from I2C0 to I2C1 as it is on the board?   

Thanks,

Hong 

Hi Hong,

Hong Zhang said:

given there are two additional devices on I2C0

Are you referring to the U17 AT24CM01 and U35 TPIC2810D?

Hong Zhang said:

and a LP filter present

Are you referring to the LPF for the I2C pins?

I'm unaware of any limitations or special setup requirements from a SW perspective. I'll let Mike comment on any HW limitations.

Can you share your loopback example code (entire CCS project) so I can help debug this issue?

Regards,
Frank

Hi Hong,

I2C is intended to be a multi device bus protocol.  As long as all the slave devices on the bus have different addresses, you can have as many slave devices on the bus as you want.  The additional two devices (EEPROM and LED drive) have addresses 0x50 and 0x60.  As long as you are configuring the slave side of your loopback test to have a different address than 0x50 and 0x60, and set the master to talk to that address, you should be fine.

Regarding the LPF, this is just to clean up the signal going into I2C0 on the AM243.  The presence of the filter does mean that when I2C0 on the AM2434 is driving either SCL or SDA low during a transaction, the other side of the filter (and what is connected to I2C1 in your loopback configuration) will see ~0.22*VSYS_3V3 as a "low".  While higher than normal, this is still below the input low max voltage for I2C of 0.3*VDD in the datasheet, where VDD corresponds to VSYS_3V3 on the LP in this case.

In addition to providing the example project for Frank, if you are able to take oscilloscope images of the SCL and SDA lines during the I2C transaction for the loopback test, and mark on the schematic where the probes are attached, that would also be helpful.

Thanks,
Mike

From I could tell, the signal has problems to go to a proper low voltage. 

Hi Hong,

Hong Zhang said:

From I could tell, the signal has problems to go to a proper low voltage. 

If you take a look at my last reply, I mentioned that the LPF would prevent the voltage from going all the way to 0V, but that as long as it was below 0.3*VDD, it would still be read as a low.  So seeing the line not go all the way to 0V is expected when I2C0 is driving the line low.  If you are concerned about this, you can replace the two series resistors in the LPFs (R93 and R97) with either shorts, or much lower resistances (i.e. 47ohm), and you will get a low that is much closer to "0V" when I2C0 drives the line.

From looking at the first waveform, it looks like I2C1 is issuing a write command to address 0x11, which is being ACK'd.  The second scope shot shows what appears to be a write to address 0x1C, which is NACK'd.

The first scope shot appears to indicate a successful I2C transaction.  To further debug your system, you need to provide your CCS project to Frank to allow him to review the full I2C configurations.

Thanks,
Mike