• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 97 subscribers
  • Views 447 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.

Can GPIO be shorted with I2C0-SCL of TMS320C6713?

Joseph CJ
Intellectual 425 points

Hi,

Is it okay to connect the GPIO pin with the I2C0-SCL pin of TMS320C6713 (see attached circuit)?

I am working on a project that requires toggling the SCL pin of I2C to release a locked-up bus. Since the I2C of TMS320C6713 doesn't allow to be used as a GPIO, I was wondering if I could connect a wire (blue line in the attached circuit) from one of the unused GPIO (grounded via 1k in my board) to the SCL pin. When in normal mode, I could leave the GPIO pin as an input pin thus letting the bus function normal. When a lock-up occurs, I could configure the GPIO as an output pin and send pulses by toggling the pin. Is this a good idea?

I looked through the datasheets, but couldn't confirm if the GPIO can sink about 1mA when it is outputting a logic low (0). Also, I am not sure if the above scheme would cause any other problems. Therefore, I would greatly appreciate if someone could provide me with any guidance.

Thank you,

Joe

  • 0
    TI__Genius 14545 points

    Hi Joe,

    If the 1K is always attached to the SCL line, you've inherently got a voltage divider here at which the clock value that the I2C slave will be is ~17% of 3.3V. -or- 0.57 Volts during the high phase of the SCL clock. (This assumes that the SCL is open drain buffer, and that there is no additional effect from GPIO being configured as an input too)

    Since the GPIO14 is also configured as an input and drawing current during the high clock phase & you have a additional 1K to ground, you're loading the I2C bus clock very heavily so I have my doubts that this circuit will produce a useable clock that will meet the timing specifications / min voltage levels of the I2C Bus. 

    You better bet would be to find a way in software in which you could toggle the SCL line without having to introduce additional loading. If not - use GPIO14 to reset the I2C slave (if possible) when a bus hang occurs rather than take a chance by incorrectly loading the bus.

  • 0 in reply to dabuan
    Intellectual 425 points

    Hi Drew,

    Thank you for your reply. It was indeed a silly mistake from my part as I did not pay attention to the potential divider formed by the two resistors. The issue I am faced with is that the board is already done, and hence, I am looking for a fix that requires minimum hardware change. A logic OR gate to club the SCL and GPIO lines might be the ideal solution, but it requires changing the PCB.

    I also looked into doing a firmware fix (see this link: http://e2e.ti.com/support/embedded/f/355/t/113346.aspx). Unfortunately, the TMS320C6713 doesn't have the feature to configure the I2C as a GPIO. Also, the slave doesn't have a reset. Adding a relay to control the power to reset the slave is not desirable due to the hardware change that will be needed.

    However, I could change the 1k to a higher value to reduce the loading and provide adequate voltage level for the clock, and add a wire to short the GPIO with SCL. Will this work?

    Thank you for all your help,

    Joe

  • 0 in reply to Joseph CJ
    TI__Genius 14545 points

    Hi Joe,

       No worries. My concern is loading the SCL line. If it's open drain, any loading will delay the rising edge of the clock an potentially violate the timing violations of the I2C bus - which might actually lock up the bus too.

        I don't have any suggestions right away. From your other post, you've done your due diligence in terms of figuring out what is the root cause.  Is there any way to prevent the temp sensor from locking up? Once a I2C slave locks up - there is typically not much you can do other than power cycle/reset.

       Do you know why the temp sensor locks up by chance?

     

  • 0 in reply to dabuan
    Intellectual 425 points

    Hi Drew,

    Thank you for your reply.

    As far as I know, it is the real time clock (RTC) that is locking up and not the temp sensor. I am waiting for another lock-up since two weeks to diagnose further and test out some code changes. Therefore, I do not know what is causing the RTC to lock-up at this point.

    Meanwhile, I am trying to get some backup solutions if the code changes I have made doesn’t help. If I can change the 1K resistor to a higher value and wire GPIO with SCL, I might be able to issue clock pulses via GPIO and recover the bus. Please do let me know if you find anything on this idea.

    Resetting the whole board is going to be hard due to the way the system is setup and would be deployed.

    Any other ways to solve my problem? Also, where can I find details on how the hardware is implemented in C6713? For example, SPRS294B says that the I2C is open-drain. Where can I find similar details on GPIO pins?

    Thank you,

    Joe