• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 102 subscribers
  • Views 537 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.

DM6435 multi-master I2C problems

Markus Moll
Expert 1820 points

Hello,


I am trying to get the I2C peripheral working on a DM6435. I started using the PSP drivers, but found that they frequently fail as soon as any abnormal condition occurs (for example, it gets stuck when the address is NACKed in a one-byte transfer (i.e. the address would be followed by a single byte only), it simply crashes (stack corruption) when a timeout occurs, ...).

I started modifying the driver, but the documentation (spru991e.pdf) leaves many details unspecified. Ultimately, the driver would have to support multi-master operation. I wonder if anyone could help me with the following questions:

  1. The note in 2.1 seems to imply that the individual roles (master/slave) are only meaningful during a transfer (which makes sense). However, there are different initialization procedures for masters and slaves. In a multi-master environment, should I stay in slave-receiver mode when idle? I guess I should.
  2. My understanding is that the device should be set in reset (ICMDR.IRS = 0) whenever it is reconfigured. Does that include setting up transfers (e.g., writing to ICCNT or ICMDR.STT/STP...)?
    1. Otherwise, are ICPSC, ICCLKH, and ICCLKL the only affected registers?
  3. Does the I2C peripheral watch the bus for other masters while it is reset (ICMDR.IRS = 0)?
    1. If the answer to 2 is yes and the answer to 3 is no, how am I supposed to start a transfer in a multi-master environment?
  4. Does setting IRS to 0 reset any other register except ICSTR? (The PSP driver goes through hoops to save ICCNT and ICCLKL/H, among others.)
  5. Does setting IRS to 0 clear all pending interrupts?
  6. spru991 contains contradicting information on what happens when ICMDR.STT is set to 1 while BB=1: 2.5 says "A repeated START condition generates when BB is set to 1 and STT is also set to 1." while Table 7 (description of ICSTR) says that AL is set and the device goes into slave-receiver mode if "The I2C attempts to start a transfer while the BB (bus busy) bit is set to 1". I guess the behavior depends on who's owning the bus?
  7. Will the device recognize its own address in a transfer during which it lost the arbitration?
  8. As a master, how can I safely abort a transfer without potentially blocking the bus? Is it safe to set ICMDR.STP=1 and ICMDR.RM = 1?

I guess that's all at the moment.

Thanks a lot

Markus

  • 0
    TI__Mastermind 35645 points

    Hi,

    Thanks for your post.

    To address #1, If the I2C peripheral is the losing master, it switches to the slave-receiver mode, sets the arbitration lost (AL) flag, and generates the arbitration-lost interrupt.

    To address#7, kindly refer section 2.9 for arbitration from the spru991e doc. below:

    http://www.ti.com/lit/ug/spru991e/spru991e.pdf

    Looking to address other questions and will update you soon

    Thanks & regards,

    Sivaraj K

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

    Please click the "Verify Answer" button on this post if it answers your question.

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

  • 0
    Mastermind 6115 points
    Hi Marcus,

    There is a wiki page which describes about some general configurations for I2C,
    I may help you out , check the below link

    processors.wiki.ti.com/.../I2C_Tips
  • 0 in reply to Arvind Singh
    Expert 1820 points
    Thank you, yes, that wiki page is helpful, I had already found it. In particular, it seems to confirm that there are a few more states than mentioned in the manual (e.g. after reception of a NACK, where setting STP=1 is sufficient to send a stop condition). The emphasis on holding the device in reset when programming the clock registers also suggests that programming all other registers is indeed safe without going into reset. I think I can consider all IRS-related questions answered.

    I have another question, however: After coming out of reset (which might still happen once in a (long) while), when does the controller detect that the bus is busy? Only at the next start condition or is any bus activity sufficient? (Another master might be busy with a potentially long transfer when I come out of reset, so the bus will be busy but there won't be any start condition). The answer will affect how long I will have to wait before I can "trust" the BB flag.