• State
  • Replies 6 replies
  • Subscribers 63 subscribers
  • Views 43 views
  • Users 0 members are here
Support feedback
Options
Options
Related

Original question:

BQ25792: BQ25792 I2C appears to lockup when USB-C power is removed and restored quickly

TPS25750: Sometimes TPS25750 returning status "0x03 task rejected" on I2Cw & I2Cr tasks after which I2Cr/I2Cw commands fail continously

Paul Saffren
Prodigy 120 points
Part Number: TPS25750
Other Parts Discussed in Thread: BQ25792, TPS25751

Tool/software:

This is a follow up to another post I made titled "BQ25792: BQ25792 I2C appears to lockup when USB-C power is removed and restored quickly"  Since that post I have added the ability to monitor the I2C traffic between the TPS25750 and the BQ25792.   It was initially thought that there was a problem between the TPS25750 and the BQ25792 communications, but this is clearly not the case.  

Our system uses a microprocessor to periodically query the BQ25792 via I2CW and I2CR tasks on the TPS25750 for voltages and charger status.  Normally everything works fine and we are able to communicate with both chips.   Intermittently the TPS25750 will return a status code of 0x03 signaling "Task Rejected" for a I2CW or I2CR task and after that no other I2CW nor I2CR tasks will complete successfully.  It's as if the I2C  "passthru" on the TPS25750 is broken.  The only way to get out of this mode is to remove the load on the BQ25792 (essentially powering off our unit).   During this failure mode the I2C lines between the TPS25750 and the BQ25792 are both in the high, pulled up state with no traffic whatsoever passing over them.   What is also interesting is that during this failure state, no communication between the TPS25750 and BQ25792 occurs.  Normally there will be traffic when I plug and unplug the USB-C cable for example.  During this failure state I can still read and write registers on the TPS25750.  It appears that only the I2Cw and I2Cr tasks are affected. 

In this scenario the BQ25792 does not have a battery attached but charging is disabled.   Also the TPS25750 is not powering the system.  Instead we are using the barrel connector input to the BQ25792.   Sometimes however, we will get the same error when running from battery and plugging and/or unplugging the USB-C PD connection.   

Questions:  Is there a hold off time/delay before I can start querying the TPS25750 and using the I2Cw/I2Cr task commads after the unit powers up/load is connected to the TPS25750 and/or BQ25792?    Is there any way to reset the TPS25750 to clear the reject task state?  

Kind regards, 

Paul 

  • 0
    TI__Guru 64411 points

    Hello,

    Do you have the ability to move over to the TPS25751 to confirm if the issue still exists?

    https://www.ti.com/product/TPS25751

    Regards,
    Chris

  • 0 in reply to Chris Sterzik
    Prodigy 120 points

    Hi Chris, 

    Thank you for the quick reply.  Unfortunately we have already built 200 units using the TPS25750.   This is new product launch and given the parts use the QFN package, it would be difficult and costly to change.  It sounds like the TPS25751 silicon may have addressed this problem, is this a known issue with the 25750? 

  • 0 in reply to Paul Saffren
    TI__Guru 64411 points

    Hello,

    It is not a known issue, but there are enhancements made.  I will keep this ticket open and work to look for a reset for the I2C engine.

    Regards,

    Chris

  • 0 in reply to Chris Sterzik
    TI__Guru 64411 points

    Hello,

    Paul Saffren said:
    Questions:  Is there a hold off time/delay before I can start querying the TPS25750 and using the I2Cw/I2Cr task commads after the unit powers up/load is connected to the TPS25750 and/or BQ25792?

    After the unit power up, the eeprom will be loaded and then the PD will send the initial config to the BQ.  This should be on the order of 550ms.

    Also be aware of the following relationships/limitations.

    Paul Saffren said:
    Is there any way to reset the TPS25750 to clear the reject task state?

    Because you cannot 'reset' the part by disconnecting, then I would recommend using the GAID or Gaid commands.

    https://www.ti.com/lit/ug/slvucr8a/slvucr8a.pdf#page=58

    Can you confirm that nothing is happening on the BQ side, clock stretch, NACK?  Is the I2C Controller NACKed bit set(unmask)?

    https://www.ti.com/lit/ug/slvucr8a/slvucr8a.pdf#page=19

    Regards,
    Chris

  • 0 in reply to Chris Sterzik
    Prodigy 120 points

    Hi Chris, 

    Thank you for answering my questions.   I implemented a 1000 ms hold off before communicating with the TPS25750 and BQ25792 however this did not eliminate the problem.  I am also very sure that we are not sending more than 14 bytes of data to the BQ25792.  All I am doing is querying the BQ25792 for ADC measurements and status bytes.  These requests are only a few bytes of data.  I also do not send I2Cw/I2Cr or write to any other TPS25750 registers faster than 10 ms between transactions.   Finally I tried using the "GAID" task command when the board got into a continuous series of 0x03 task reject loop and it had no effect. 

    One thing I have noticed is that when we are in this failed state, and this may be the issue;  reading register 0x03 of the TPS25750 shows the mode to be "PTCH" and not "APP".   What I don't understand is why the chip intermittently does not go into APP mode.   We are pin strapping the TPS25750 with  both ADC1IN and ADC2IN connected to LDO_1D5 which should put us into "AlwaysEnableSink" .  Curious if we should pin strap for "SafeMode" since we load from an EEPROM?   

    Regards, 

    Paul

  • 0 in reply to Paul Saffren
    Prodigy 120 points

    Chris, 

    Just to clarify in your last post, are you saying I have to wait 5 SECONDS between I2Cr/I2Cw operations?  Or is that a typo and you meant to say 5 milliseconds? 

    Paul