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

AM3352 unreliable I2C operation

sujeeva wettasinghe
Intellectual 460 points
Other Parts Discussed in Thread: AM3352, TPS65910

Hi Ti,

My customer has the following questions about I2C opration on AM3352.

We are currently experiencing some stability problems with the TI 3352 CPU in the field with our product. We are having frequent issues during boot which is affecting long term stability in the field. Once booted successfully it seems fine.

Our processor board uses a TPS65910AA1RSL power controller, connected to the AM3352 processor via I2C. There are no other devices fitted on the I2C bus, except a pair of pull-up resistors.

We experience unreliable I2C operation during early kernel boot, with individual I2C transactions failing (no ACK).

The effect of this depends on which particular transactions have failed, since a lot of the transactions of the power regulator driver are effective no-ops. Most of the time, there is no problem, but worst case we see that the regulator device is not recognised at all by the driver.

Our design only requires the 5V rail (SW3) to be programed to supply VBus for USB, all others are used in their default configuration. We only see an operational error if VBus is missing.


We are aware of the repeated start condition errata of the TPS65910, but as far as I can tell, this situation does not occur here.


We have added a wait-and-retry loop to the regulator driver, which has improved things a lot, but we have reason to believe that sometimes failure occurs despite that. The loop gives up after 10 retries. In most cases, the transaction succeeds after
1-2 tries.

There also seems to be a interesting correlation: using engineering silicon (XAM335x) apparently reduces the error frequency when compared to production silicon (AM335x).

There are no obvious issues with the signals when watched on an oscilloscope.

 

Sujeeva Wettasinghe

Avnet FAE

  • 0
    TI__Guru**** 393215 points
    Hi Sujeeva,
     
    What AM335X silicon revisions do you use? There is an I2C errata 1.0.26 - have you checked it? What are the values of your I2C pullups and what power rail are they connected to?
  • 0 in reply to Biser Gatchev-XID
    Intellectual 460 points

    Hi Biser,

    This part has the issue

    This one seems to be more reliable but it may be a co-incidence:

    I2C pullups are currently 1K. We did notice that the pullup value is somewhat critical. They are connected to the 3V3 as is the TPS65910AA1RSL power supply chip rail.

    We have read the errata and are can see you are on the right track. A bit concerning.

    As the errata says, the I2C pads are occasionally *driving* the lines high, causing noise on the bus and potentially fighting ACKs. Apparently, we have seen rare "bus arbitration errors", despite this being a single master system - this too is now explained.

    The errata suggests fitting serial resistors to reduce the ringing. Problem is that the PCBs are in the field and any HW mods are impossible.

    Can TI suggest anything that we can do in the software to fix this problem?

    Regards,
    Sujeeva

  • 0 in reply to sujeeva wettasinghe
    TI__Guru**** 393215 points
    Hi sujeeva,
     
    From what I see your processors are silicon Rev.1.0, so the errata applies to them. This issue has been solved in silicon Rev.2.X. Obviously you cannot patch with serial resistors, but if possible I would suggest you raise the pullup resistors value to 3.3 - 4.7kOhm (see Table 6 in the Errata).
  • 0 in reply to Biser Gatchev-XID
    TI__Guru 59735 points

    Update to last post:

    The I2C issue described in Advisory 1.0.26 of the AM335x Silicon Errata was fixed in silicon revision 2.1, not silicon revision 2.0.  Therefore, Biser's comment above should have said 2.1 rather than 2.x.

    Regards,
    Paul