TMS320F28386D: I2C communication problem "i2c_ex2_eeprom" TI example

Hello Gianni,

If you run the normal example, can you confirm that the oscilloscope shows the proper clocking/data? If so then yes, this means something in your changes was not done properly.

I can not able to run the normal example because I use a custom board with constrains of connection (assigned pin that I can not change).

Hi,

Have you already reviewed the Interface EEPROM Using I2C? Are the lines for SCL and SDA stuck high or low since they're not changing?

Hello,

I used this type of EEPROM for others I2C applications with others custom board and it worked correctly (I'm using the same rule to connect the pins between EEPROM and DSP).

I see SDA and SCL pins always low at the moment.

In attached my edited project.

i2c_ex2_eeprom.rar

Gianni L said:

I used this type of EEPROM for others I2C applications with others custom board and it worked correctly (I'm using the same rule to connect the pins between EEPROM and DSP).

I see SDA and SCL pins always low at the moment.

In the previous I2C applications you had, was it with this same TI device? If the SDA and SCL pins are always low, it sounds like their may not be sufficient pull-up strength. By default, the lines should be high as in with any I2C protocol (the falling edges of SDA/SCL indicate the start of a data frame). Is this issue happening on more than one board or have you only tested this with the current hardware you're using?

Omer Amir said:

In the previous I2C applications you had, was it with this same TI device?

It was used TMS320F28377D and the same EEPROM.

Omer Amir said:

Is this issue happening on more than one board or have you only tested this with the current hardware you're using?

I have tested only this board at the moment.

Omer Amir said:

If the SDA and SCL pins are always low, it sounds like their may not be sufficient pull-up strength.

Sorry, my mistake, I see always 3.3V in SDA and SCL pins.

Gianni L said:

Sorry, my mistake, I see always 3.3V in SDA and SCL pins.

Oh, so the pin never goes low? If you try to use it as a GPIO and set it to output low is there any issue?

Gianni L said:

It was used TMS320F28377D and the same EEPROM.

Were there any hardware or software changes beyond changing the C2000 device?

Omer Amir said:

If you try to use it as a GPIO and set it to output low is there any issue?

I setted SDA low and it stay low and after I setted SCL low and it stay low correctly.

Omer Amir said:

Were there any hardware or software changes beyond changing the C2000 device?

The hardware for these pins is the same (with the pull-up resistors) like the other board.

Hello Gianni,

Since this doesn't seem to be a hardware issue, I will try to emulate this setup.

Hello Gianni,

I used the example on my side and found that using GPIO40 and GPIO41 for I2C B seemingly worked fine, but using GPIO2 and GPIO3 had an issue where the clock went but didn't clock and the data line remained high. This issue doesn't seem to be isolated to your device, at least from my testing. There is no note or known issue about this, so I will ask design team to see if they might know why this is the case.

Hello Omer,

Thank you for the feedback, so I will wait some news about that.

I should be able to get a response by the end of the week, but I'll let you know if anything changes.

Hello Gianni,

Have you verified that i2c_ex1_loopback and i2c_ex3_external_loopback work fine for you? The design team was not able to replicate the same issue (the issue I saw might be related to something else, I did not have a proper setup), so I'm wondering if you test those two examples if you can see the sData, rData, and rDataPoint values changing in the CCS Expressions window. I verified this on the F28388D ControlCARD and saw that the communication seemed to be happening.

If these examples work, trying using that as a basis for communicating with your EEPROM.

Hello Omer,

I tried "i2c_ex1_loopback" example (editing through SysConfig the pins for I2CB) and it does work correctly.

This means that something goes wrong changing the code from I2CA to I2CB on "i2c_ex2_eeprom" example? Or an hardware issue? Because "i2c_ex1_loopback" does not exclude these two hypothesis (with i2c_ex1_loopback we are just testing the I2C module).

Gianni L said:

This means that something goes wrong changing the code from I2CA to I2CB on "i2c_ex2_eeprom" example? Or an hardware issue?

Please try to also do i2c_ex3_external_loopback as I recommended, modifying the configuration code to use GPIO2/3 for I2C B. Verify whether this works or fails, like you stated example 1 is just an internal check to make sure the I2C itself is not a problem. Example 2 uses the actual pins, which I tested on a ControlCARD without issue. If this works, then that means the example itself needs to be addressed.

Omer Amir said:

Please try to also do i2c_ex3_external_loopback as I recommended, modifying the configuration code to use GPIO2/3 for I2C B. Verify whether this works or fails, like you stated example 1 is just an internal check to make sure the I2C itself is not a problem. Example 2 uses the actual pins, which I tested on a ControlCARD without issue. If this works, then that means the example itself needs to be addressed.

By trying the "i2c_ex3_external_loopback" example and I don't see the sData, rData, and rDataPoint values changing in the CCS Expressions window.

This is the setup that I've used:

//I2CA GPIO pins
#define DEVICE_GPIO_PIN_SDAA 0
#define DEVICE_GPIO_PIN_SCLA 1

//I2CB GPIO pins
#define DEVICE_GPIO_PIN_SDAB 2
#define DEVICE_GPIO_PIN_SCLB 3

#define DEVICE_GPIO_CFG_SDAA GPIO_0_I2CA_SDA
#define DEVICE_GPIO_CFG_SCLA GPIO_1_I2CA_SCL

#define DEVICE_GPIO_CFG_SDAB GPIO_2_I2CB_SDA
#define DEVICE_GPIO_CFG_SCLB GPIO_3_I2CB_SCL

Gianni L said:

By trying the "i2c_ex3_external_loopback" example and I don't see the sData, rData, and rDataPoint values changing in the CCS Expressions window.

Did you externally connect the I2C A and I2C B SDA/SCL pins respectively? If so and you still didn't see any values changing, this is a sign that the problem may be caused by something in your hardware, I suggest double-checking on another board/available device if possible. I tested on a ControlCARD without issue, so it should connect successfully.

Omer Amir said:

Did you externally connect the I2C A and I2C B SDA/SCL pins respectively? If so and you still didn't see any values changing, this is a sign that the problem may be caused by something in your hardware, I suggest double-checking on another board/available device if possible. I tested on a ControlCARD without issue, so it should connect successfully.

I thought it was not necessary to make the physical connection of pins for this example.

Unfortunately it is not possible to connect the pins for this custom board, so I can not try this example.

Gianni L said:

I thought it was not necessary to make the physical connection of pins for this example.

The example is specifically called external loopback, the description of the example at the top of the main source file also describes this.

Gianni L said:

Unfortunately it is not possible to connect the pins for this custom board, so I can not try this example.

Since I'm able to verify this on the ControlCARD, it's not clear to me whether this is an issue with your hardware or a problem with the software example. If there is absolutely no way for you to try to connect the pins together, I will try to continue working with the design team to see if they can replicate this issue or not, although I expect there may be at least a week delay or longer.

Hello Omer,

I will search a way to do this test and I will give you a feedback. Thank you.