TMS320F280039C: I2C communication error with EEPROM AT24C02C

Hi Jaehoon,

Some suggestions on where to look for what is causing this issue: 

1. Correct Data Count: Verify that the msg->numBytes matches the number of data bytes set via I2C_setDataCount.
2. Address Check: Verify the TARGET_ADDRESS is correct and matches the address of the EEPROM. 
3. Timing and Delays: Since an EEPROM page read / write can take up to 5 ms, ensure that there is a 5ms delay every 8 bytes. 

Best Regards,

Aishwarya 

As you can see, Most of write is done well, but the red box has problem.

After red box, I2C data changed from [write] [address] [data 8byte] to  [address] [data 8byte] [write]

1. numbytes is fixed as 8,

2. Address is correct because I can read EEPROM with same address(0x50)

3. Timing is correct(5ms) as you can see and same problem is happen when I changed delay from 5ms to 10ms.

Can you check if this problem is related to https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1243800/tms320f28388d-i2c-in-free-data-format-mode-sends-address-anyway/4704256?tisearch=e2e-sitesearch&keymatch=startcondition#4704256 

Jaehoon,

Can you confirm the following? 

Jaehoon Jeong said:

//
// Setup number of bytes to send msgBuffer and address
//
I2C_setDataCount(I2CA_BASE, (msg->numBytes + 1));

When numBytes is set to 8, this line ‘msg->numBytes’ is equivalent to 9 so I2CCCNT gets set to 9 via the function?

Jaehoon Jeong said:

for (i = 0; i < msg->numBytes; i++)
{
I2C_putData(I2CA_BASE, msg->msgBuffer[i+Blackbox_index]);
}

In this loop, the I2C is looping through 9x? Is this the desired configuration?

Jaehoon Jeong said:

Can you check if this problem is related to https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1243800/tms320f28388d-i2c-in-free-data-format-mode-sends-address-anyway/4704256?tisearch=e2e-sitesearch&keymatch=startcondition#4704256 

If you’re in FDF, possibly. Let me know if you’ve followed the suggestions in the thread and if that has helped.

Best Regards

1. I checked that I2CCNT is 9.

2. for (i = 0; i < msg->numBytes; i++)
    {
        I2C_putData(I2CA_BASE, msg->msgBuffer[i+Blackbox_index]);
    }

In above code, MCU put 8bytes of data byte in to I2C buffer because 'msg->numBytes' is 8

I2C write packet is total 10bytes

    1th byte : 7bit EEPROM device address(I2C slave address) / 1bit Write

    2th byte : EEPROM memory address

    3~10th byte : Data

Also, I checked FDF bit in I2CMDR is 0.

Hi Jaehoon,

This expert is currently out of office until 7/1. Please expect a delay in response until then. Thank you for your patience.

Best Regards,

Allison

One more thing, I checked I2caRegs.I2CSTR -> XSMT bit is 0 right after I2C send 11bytes ( [write] [address] [data 8byte] [write] ).

Could you confirm any possibility of occuring XSMT bit 0 during Normal I2C communication.

Capture of I2caRegs during normal operation.

------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Caputure of I2caRegs right after wrong communication ( [write] [address] [data 8byte] [write] )

I found how to solve this problem but I don't know root cause of this issue.

Could you explain why problem is occur when it doesn't have delay between StartCondition and StopCondition?

Before :

   I2C_sendStartCondition(I2CA_BASE);
   I2C_sendStopCondition(I2CA_BASE);

After :

   I2C_sendStartCondition(I2CA_BASE);
   DEVICE_DELAY_US(10); // Problem doesn't occur with this delay
   I2C_sendStopCondition(I2CA_BASE);

Jaehoon,

Aishwarya Rajesh said:

Timing and Delays: Since an EEPROM page read / write can take up to 5 ms, ensure that there is a 5ms delay every 8 bytes. 

Adding the delay ensures that the software accounts for the maximum time an EEPROM can read / write a page according to the EEPROM datasheet. Without the delay, after an EEPROM write operation, it will still be busy writing the data and cannot respond until it is finished with the write.

Since typically the time mandated in the datasheet is about 5 ms, 10 clock cycles is a good number to use.

Best Regards,

Aishwarya 

I'm not sure if you really read my reply.

The delay that I added is between Startcondition and Stopcondition and it is just a 10us delay.

I use below code for writing to EEPROM and below code is reference code by TI C2000ware

uint16_t writeData(struct I2CMsg *msg)
{
    uint16_t i;

    I2C_setSlaveAddress(I2CA_BASE, TARGET_ADDRESS);

    I2C_setDataCount(I2CA_BASE, (msg->numBytes + 1));

    I2C_putData(I2CA_BASE, msg->memoryAddr);

    for (i = 0; i < msg->numBytes; i++)
    {
        I2C_putData(I2CA_BASE, msg->msgBuffer[i+Blackbox_index]);
    }

    I2C_setConfig(I2CA_BASE, I2C_MASTER_SEND_MODE);
    I2C_sendStartCondition(I2CA_BASE);
    I2C_sendStopCondition(I2CA_BASE);

    return(SUCCESS);
}

This "writeData" function write 8bytes to EEPROM, and there is another 5ms delay between writeData and writeData in my code.

writeData() - 5ms delay - writeData() - 5ms delay - .....

What I added into code is just 10us delay between StartCondition and StopCondition like below.

    I2C_sendStartCondition(I2CA_BASE);

    DEVICE_DELAY_US(10); // I just add 10us delay between StartCondition and StopCondition and it solve the problem.

    // Problem occurs even though I put 10ms delay between writeData() and writeData() without this "10us delay"

    I2C_sendStopCondition(I2CA_BASE);

Please advise why this delay in 10us solves the problem

Any feedback?

Jaehoon,

I will get back to you with my response on Monday, July 8th. Thank you for your understanding.

Aishwarya

How is it going?

Hi Jaehoon,

Aishwarya is located in a region affected by the Hurricane Beryl and may not be able to respond for the next 2-3 days. Please expect a delay in response till the time she is back. Thanks for understanding. 

When can I get answer from TI?

Jaehoon,

Apologies for the delay. Similar to what I was saying before, I2C needs to follow certain timing requirements between start and the subsequent stop conditions to operate properly. If the stop condition occurs too soon after the start condition, there might be interference with I2C initialization or the ACKing between the MCU and EEPROM (this is the issue happening here). On the same note, the EEPROM also needs certain amount of time to complete its tasks before the controller terminates the communicates sequence.

In the given C2000Ware examples, there are delays to both correctly read I2C bus status as well as wait for the EEPROM write cycle time before initiating the read/write transaction.

Jaehoon Jeong said:

    // Problem occurs even though I put 10ms delay between writeData() and writeData() without this "10us delay"

The reason this probably didn't fix the issue is because the doesn't take care of any delays needed inside writes (this is taken care in hardware) and take into account bus arbitration rules.

Best Regards,

Aishwarya