• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 81 subscribers
  • Views 781 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TMS320F280049: i2c configuration

Vineeth N
Expert 1180 points
Part Number: TMS320F280049


Hi team,

While going through i2c section in TRM I came across this.

 

I didn`t really get it.

1.What is meant by wait for a period longer than longest data transfer ? how do we find it, the longest data transfer?. 

2. It is said that by waiting for such a long time we can capture a START or STOP and it will be captured by BB bit. My doubt is that even before we initiate a communication how can the device capture START or STOP signal ? Since communication itself start only after START signal which is set by the user

Thank you,

Vineeth

  • 0
    TI__Guru 55700 points

    Vineeth,

    I think this information was added recently. Let me check with concerned engineer and get back with you in 2 - 3 business days.

    Regards,

    Manoj

  • 0 in reply to Manoj Santha Mohan
    Expert 1180 points

    Hi Manoj,

    Thank you for your response. I will wait for your answer.

    Best regards,

    Vineeth

  • 0 in reply to Manoj Santha Mohan
    TI__Guru 55700 points

    Vineeth,

    After C2000 I2C comes out of reset, BB bit may not correctly reflect I2C bus state. It requires either START (or) STOP condition after reset for BB bit to correctly reflect the state of bus.So, after taking I2C out of reset wait for time period equivalent to time taken for 16 (FIFO max length) bytes of I2C data are transferred before checking busy bit (BB).

    This information  should have been worded better. I will file a ticket and fix this in next release of TRM.

    Regards,

    Manoj

  • 0 in reply to Manoj Santha Mohan
    Expert 1180 points

    Hi Manoj,

    Thank you for your response.

    Unfortunately I still didn`t get this right, can you be a little more elaborate please. I have some doubts,

    Manoj Santha Mohan said:
    It requires either START (or) STOP condition after reset for BB bit to correctly reflect the state of bus.So, after taking I2C out of reset wait for time period equivalent to time taken for 16 (FIFO max length) bytes of I2C data are transferred before checking busy bit (BB).

    After i2c comes out of reset state, should we wait without doing anything for a START or STOP signal to be detected?.

    If I am using 20 SPS then for each transfer it will take approximately 50 millisecond for each transfer. So as you said if I have to wait for 16 byte transfer time, then it will be roughly 16*50 = 800 millisecond right? Will it be a long delay? 

    Or should we need to generate START or STOP manually?. Since according to my understanding without setting STT bit or STP bit the START or STOP condition will not be generated.

    What I have done is that after taking i2c out of reset I have given ADC reset command to peripheral ADC. Is this is correct way to start communication?. I haven`t checked for BB before starting communication. The following is the snippet from my code

            I2caRegs.I2CMDR.bit.IRS             = 1; // I2C is enabled

        GpioDataRegs.GPBSET.bit.GPIO34      = 1; // ADC released from reset state

        I2caRegs.I2CSAR.bit.SAR             = 0x41; // Slave address register

        I2caRegs.I2CCNT                     = 1; // Data count
        I2caRegs.I2CDXR.bit.DATA            = 0x06; // RESET command
        I2caRegs.I2CMDR.all                 = 0x6E20; // I2CMDR = ICMDR_FREE | ICMDR_STT | ICMDR_STP | ICMDR_MST | ICMDR_TRX | ICMDR_IRS | ICMDR_BC

    Best regards,

    Vineeth 

  • 0 in reply to Vineeth N
    TI__Guru 55700 points

    Vineeth,

    After you bring I2C out of reset by setting IRS bit, you need to wait for atleast 1.3ms (in case of 100KHz standard mode) (or) 320 us (in case of 400 KHz fast mode). After this time period, BB bit will correctly reflect the status of bus. If I were you instead of wasting my CPU cycles on wait time, I would be performing other tasks during that wait time. Other than the wait time and not checking busy bit, I don't see anything wrong in your code assuming you have taken care of configuring I2C properly.

    Regards,

    Manoj

  • 0 in reply to Manoj Santha Mohan
    Expert 1180 points

    Hi Manoj,

    Thank you for your replay. Now I have a clear understanding of the statement. 

    For others if who are reading this thread, in the previous post I have calculated data transfer time wrongly. I have calculated it based on input sampling rate i.e. 20SPS. The data is actually clocked out based on i2c master clock which is 100 kHz in my case. So, for 16 byte transmission the time required will be  16*8*10 micro seconds = 1.28 milliseconds. Like wise you can calculate for other modes also which is mentioned by Manoj here.

     

    Manoj Santha Mohan said:
    wait for atleast 1.3ms (in case of 100KHz standard mode) (or) 320 us (in case of 400 KHz fast mode)

    Thank you for your support Manoj.

    Best Regards,

    Vineeth