• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 2 answers
  • Subscribers 29 subscribers
  • Views 406 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

DLPC350: About I2C access of DLPC350

user6036569
Intellectual 505 points
Part Number: DLPC350

Hi Mayank,or TI expert

I have a question about I2C access of DLPC350.

Currently, DLPC350 firmware fair Ver1.1
We are operating the equipment used.

However, there is an I2C hang problem
Change to firmware Ver4.1 or 4.4
I'm trying to solve this problem.

The release notes for Ver4.1 have the following description.
- Solved I2C Bus Hangup Issue - I2C Bus getting hung up indefinitely when
sending back to back commands.
- Added option to have a selectable GPIO that indicates I2C Command exectuion
status: I2C_BUSY GPIO.

I have a question about "I2C_BUSY GPIO".
Please answer each question.

(1) Is this "I2C_BUSY GPIO" a necessary condition to solve the I2C hangup?
Ans →
(2) Where can this terminal be assigned to GPIO?
Ans →
(3) Can this terminal become BUSY even if I2C processing is not performed?
Ans →
④ Does Ver4.4 also have "I2C_BUSY GPIO"?
Ans →

Seeking an accurate answer quickly.

Regards,

Tak

  • 0
    TI__Genius 12575 points

    Hello Tak-san,

    Welcome back to the E2E forum.

    This E2E post explains how to properly configure I2CBUSYGPIO.

    (1) Is this "I2C_BUSY GPIO" a necessary condition to solve the I2C hangup?
    Ans → Can you speak more on this hanging issue? It is somewhat unclear in your post. Are you using 4.1 previously and 4.4 is giving a hanging I2C?
    (2) Where can this terminal be assigned to GPIO?
    Ans → See above post. Valid GPIO numbers are: 14,15, 20, 21, 25, 27, 28, 29, 33, 34, 35, 36
    (3) Can this terminal become BUSY even if I2C processing is not performed?
    Ans → If properly configured the I2C BUSY GPIO should only be raised when the controller is processing an I2C command as explained in the linked post.
    ④ Does Ver4.4 also have "I2C_BUSY GPIO"?
    Ans → This should be the case, but I will confirm.

    Regards,

    Austin

  • 0 in reply to Austin Snyder
    Intellectual 505 points

    Hi Austin

    Thanks Austin

    (1) Is this "I2C_BUSY GPIO" a necessary condition to solve the I2C hangup?
    Ans → Can you speak more on this hanging issue? It is somewhat unclear in your post. Are you using 4.1 previously and 4.4 is giving a hanging I2C?
    Tak → I'm sorry.We are currently using v1.0.
    I'm trying to change to v4.1 to resolve the hang. Is "I2C_BUSY GPIO" a requirement to solve the hang-up problem?
    Ans →

    (2) Where can this terminal be assigned to GPIO?
    Ans → See above post. Valid GPIO numbers are: 14,15, 20, 21, 25, 27, 28, 29, 33, 34, 35, 36
    Tak → I understand.

    (3) Can this terminal become BUSY even if I2C processing is not performed?
    Ans → If properly configured the I2C BUSY GPIO should only be raised when the controller is processing an I2C command as explained in the linked post.
    Tak → I understand.

    (4) Does Ver4.4 also have "I2C_BUSY GPIO"?
    Ans → This should be the case, but I will confirm.
    Tak → Please confirm.
    Ans →

    (5) It is an additional question.
    Can firmware v4.1 solve the hang problem without using "I2C_BUSYGPIO"?
    Ans →

    Regards,

    Tak

  • 0 in reply to user6036569
    TI__Mastermind 22830 points

    Hello Tak,

    We need to check with team members and get back to you on these follow-up questions.

    regards,

    Vivek

  • 0 in reply to user6036569
    TI__Expert 3425 points

    Hi Tak

    (1) Is this "I2C_BUSY GPIO" a necessary condition to solve the I2C hangup?

    Ans → Can you speak more on this hanging issue? It is somewhat unclear in your post. Are you using 4.1 previously and 4.4 is giving a hanging I2C?
    Tak → I'm sorry.We are currently using v1.0.
    I'm trying to change to v4.1 to resolve the hang. Is "I2C_BUSY GPIO" a requirement to solve the hang-up problem?
    Akhil → Yes I2C_BUSY GPIO  is needed to solve the hangup issue. I2C_BUSY GPIO is intended to prompt the I2C bus master that the bus is busy, So the I2C bus master(host MCU) can take appropriate action accordingly. 

    (2) Where can this terminal be assigned to GPIO?
    Ans → See above post. Valid GPIO numbers are: 14,15, 20, 21, 25, 27, 28, 29, 33, 34, 35, 36
    Tak → I understand.

    (3) Can this terminal become BUSY even if I2C processing is not performed?
    Ans → If properly configured the I2C BUSY GPIO should only be raised when the controller is processing an I2C command as explained in the linked post.
    Tak → I understand.

    (4) Does Ver4.4 also have "I2C_BUSY GPIO"?
    Ans → This should be the case, but I will confirm.
    Tak → Please confirm.
    Akhil →Yes, it is included

    (5) It is an additional question.
    Can firmware v4.1 solve the hang problem without using "I2C_BUSYGPIO"?
    Akhil → No, The I2C_BUSYGPIO is required for stabilizing the I2C communication. The way this works is that when the I2C command bytes are sent, The I2C Busy GPIO is pulled high at this point. Once the command is executed the GPIO is pulled low. This I2C Busy GPIO must be polled by the Master(host MCU) sending the bytes and should take a decision to send based on whether the GPIO is high or low.

    Regards,

    Akhil

  • 0 in reply to Akhil Guntumadugu
    Intellectual 505 points

    Hi Akhil

    Thanks Akhil

    (1) Is this "I2C_BUSY GPIO" a necessary condition to solve the I2C hangup?

    Ans → Can you speak more on this hanging issue? It is somewhat unclear in your post. Are you using 4.1 previously and 4.4 is giving a hanging I2C?
    Tak → I'm sorry.We are currently using v1.0.
    I'm trying to change to v4.1 to resolve the hang. Is "I2C_BUSY GPIO" a requirement to solve the hang-up problem?
    Akhil → Yes I2C_BUSY GPIO is needed to solve the hangup issue. I2C_BUSY GPIO is intended to prompt the I2C bus master that the bus is busy, So the I2C bus master(host MCU) can take appropriate action accordingly.
    Tak → I understand.


    (4) Does Ver4.4 also have "I2C_BUSY GPIO"?
    Ans → This should be the case, but I will confirm.
    Tak → Please confirm.
    Akhil →Yes, it is included
    Tak → I understand.

    (5) It is an additional question.
    Can firmware v4.1 solve the hang problem without using "I2C_BUSYGPIO"?
    Akhil → No, The I2C_BUSYGPIO is required for stabilizing the I2C communication. The way this works is that when the I2C command bytes are sent, The I2C Busy GPIO is pulled high at this point. Once the command is executed the GPIO is pulled low. This I2C Busy GPIO must be polled by the Master(host MCU) sending the bytes and should take a decision to send based on whether the GPIO is high or low.
    Tak → I understand.

    (6) It is an additional question.

    Other engineer are present in I2C response data
    I heard that you are using "busy bit".

    For details, see the following items in the "DLPC350 Programmer's Guide".

    "2.4.3.1 Validate Data Command Response"->
    "Table 2-52. Validate Data Command Response"

    Is this method the same effect as "I2C_BUSYGPIO"?
    Can you confirm it?

    Please let me know if there is a problem with this method.

    Regards,

    Tak

  • +1 in reply to user6036569
    TI__Genius 12575 points

    Hello Tak,

    I am somewhat uncertain on your last question.

    Section 2.4.3.1 is unrelated to I2C_BUSYGPIO. The command is specifically meant to check programmed pattern display modes. The busy bit mentioned in this section is specific to the DLPC being busy validating the patterns.

    I hope this was helpful.

    Kind regards,

    Austin