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.

AM2612: AM2612 as I2C slave, when master send command to AM2612, how can I distinguish this command is READ command or WRITE command

Part Number: AM2612

Tool/software:

Hello TI support team:

   AS the decription of titile.  AM2612 as I2C slave, when master send command to AM2612, how can I distinguish this command is READ command or WRITE command?

 Is there any register of I2C to indicate it? or can I read some variables in sdk of I2C(  i2c_v1.c   i2c_v1_lld.c) ? 

Waiting for your responese.  Thanks very much.

  • Hi Jevin,

    Let me look into it and get back,

    Regards,
    Shaunak

  • Hi Jevin,

    You can check the direction of the Target. You can read the I2C_ICSTR register's (0x52500008h) 14th BIT for the direction. You can find the details in the AM261x Register Addendum: www.ti.com/.../spruj94a.pdf

    Regards,
    Shaunak

  • Hello Shaunak,

        Thanks for your reply. I will check this register in case of both I2C master read and write AM2612(I2C Slave). 

  • Hello Shaunak,

         Sorry for relpy so late. I have tried to send both read and write commands separately.  Register  I2C_ICSTR value is 0x1610 in both case. When I2C Slave send the data to I2C bus, this value is 0x5610. In my understand,  I2C_ICSTR register's (0x52500208h for I2C 2) 14th BIT indicate the I2C instance is a transmitter or a receiver. But not indicate I2C instance receive a WRITE command or READ command.

    Anyway, this question is not important for me now.   Another question is very important for me.

    As the screen shot, SCL keep in low level in a very long time and CAN NOT release to high level any more. Do you ever  handle this case?  How do I analyze this issue? 

    Waiting for your response. Thanks very much.

     

  • Hi Jevin,

    As the screen shot, SCL keep in low level in a very long time and CAN NOT release to high level any more. Do you ever  handle this case?  How do I analyze this issue? 

    When do you encounter this condition? I do some I2C read and writes and don't see the SCL line being pulled low for a long time.

    1. Can you share what was the last operation performed before you see a long low on SCL line

    2. How long is the SCL low for?

    3. Is any I2C transaction going bad/stuck in a faulty state?

    4. Do you suspect clock stretching?

    5. Is this default AM261x-LP and out-of-box SDK example? If yes, can you share details so I can try as well? I tried the AM261x v10.02.00.15 SDK example for I2C Led blink and did not see this issue with I2C1.

    Regards,
    Shaunak