• State Answer Suggested
  • Replies 12 replies
  • Answers 1 answer
  • Subscribers 67 subscribers
  • Views 160 views
  • Users 0 members are here
Support feedback
Options
Options
Related

TPS25751: Handling failure modes in embedded controller SW

Brian Antheunisse
Expert 5305 points
Part Number: TPS25751

Tool/software:

Team,

Customer is designing the device driver for TPS25751 and wanted to check on how to handle failure modes. Here are the few scenarios I have identified so far:

  1. PBMs fail:
    1. For a !CMD error, is the driver expected to execute some sort of a reset like GO2P/Gaid/GAID? If not, can we expect to receive INT_EVENT1.ReadyForPatch after some sort of timeout?
    2. CMD1 = 0 but DATAX returns an error. From the error codes on DATAX, it looks like the only recovery would be update the software. No runtime recovery is possible. *Can you confirm*?
  2. PBMc fail:
    1. For a !CMD error, it is expected to issue a PBMe. Again, can we expect to receive INT_EVENT1.ReadyForPatch after some sort of timeout?
    2. CMD1 = 0 but DATAX returns an error. From the error code in DevicePatchCompleteStatus, it looks like all errors except 0x20 (not ready) cannot be recovered runtime. *Can you confirm*?
  3. Other failures
    1. Let’s say patch bundle fails midway. What sort of signal can we use from the TPS to determine this has occurred?

 

Let me know if I might have missed something.

Regards,

Brian Antheunisse

  • 0
    Prodigy 70 points

     Looks like you have captured my questions. Will wait for the teams response

  • 0 in reply to Nihir Kumar
    Prodigy 70 points

    Another query I want to add is around 'I2Cr' - I2C Read Transaction. In the additional function section, there's a comment: "The 'I2Cr' command cannot be sent within 5s from sending a previous 'I2Cr' command. This allows the PD controller to
    complete all I2C transactions"

    Does this mean the software needs to wait for 5s before continuing with I2C transactions?

  • 0 in reply to Nihir Kumar
    Intellectual 330 points
    • Implementation:
      • Use a timer in the EC driver to track the time since the last I2Cr command.
      • Before sending a new I2Cr, check if 5 seconds have elapsed. If not, delay the command.
      • Monitor CMD1Complete (0x14, bit 30) to confirm the previous I2Cr completed successfully before initiating the next.
    • Action: Add a 5-second guard timer in your driver for I2Cr commands. Use interrupts or polling to confirm command completion via 0x14.                              

      Summary for Driver Design

      • PBMs !CMD: Issue GO2P, wait 100 ms, check ReadyForPatch. Retry or power cycle.
      • PBMs DATAX Error: Update patch configuration; no runtime recovery except for transient errors.
      • PBMc !CMD: Send PBMe, wait 100 ms, check ReadyForPatch, retry or reset.
      • PBMc DATAX Error: Retry for 0x20; update patch for other errors.
      • Patch Midway Failure: Monitor 0x14 (errors, PatchLoaded) and 0x2D (PatchHeaderError). Use PBMe/GO2P for recovery.
      • I2Cr: Enforce a 5-second delay between commands in the driver.
      • General: Log all error codes (0x14, 0x2D, DATAX), ensure robust I2C communication (e.g., verify ACKs), and test in your EV charger’s noisy environment.
  • 0 in reply to SUNILBHAI PATEL
    Prodigy 70 points

    Hi SunilBhai,

    Thanks for the response. Can you also tell me how to handle the 1 byte task return code for other 4CC tasks.

    Also, apart from I2C_NACK, what error codes can we unmask on register 0x14 that can help us 

  • 0 in reply to Nihir Kumar
    Prodigy 70 points

    Any side effects of calling DBfg more than once?

  • 0 in reply to Nihir Kumar
    TI__Mastermind 34436 points

    Hi Nihir, 

    Nihir Kumar said:
    Can you also tell me how to handle the 1 byte task return code for other 4CC tasks.

    Can you specify which 4CC tasks you're referring to here? There are different reasons for a 4CC task to be rejected such as timeouts, locked buffer, etc. See table below for more details:

    Nihir Kumar said:
    Also, apart from I2C_NACK, what error codes can we unmask on register 0x14 that can help us 

    One INT you can utilize is the CMD1 Complete [30] , this INT will let you know when the 4CC tasks is accepted and has sent a return code (either successful or not successful). 

     

    Thanks and Regards,

    Raymond Lin

  • 0 in reply to Raymond Lin
    Prodigy 70 points

    Hi Raymond,

    I'm referring to PBMe, GO2P, DBFg, I2Cr. I'm guessing these return the standard task return codes.

    The interrupts I'm utilizing are I2C_NACK and CMD1 complete. Are there any others I can turn on that'll help? 

  • 0 in reply to Nihir Kumar
    TI__Mastermind 34436 points

    Hi Nihir, 

    Let me check on those commands and get back to you by tomorrow. I do not recommend using GO2P for error recovery, this command is intended to only bring the PD back into PTCH mode if the Dead Battery configuration is set to NegotiateHighVoltage (refer to datasheet). 

    For the interrupt events, I2C_NACK and CMD1 complete should be good enough. The PD controller also has Patch Loaded [80] and Ready For Patch [81] enabled by default before a config is loaded, I would highly recommend to not disable these when you're enabling the other two interrupts. 

    Thanks and Regards,

    Raymond Lin

  • 0 in reply to Raymond Lin
    Prodigy 70 points

    What would be your recommendation for error recovery if not GO2P?

  • 0 in reply to Nihir Kumar
    TI__Mastermind 34436 points

    Instead of GO2P, you should use GAID (cold reset) for error recovery to reboot the PD controller from its ROM code.

    Keep in mind if the PD controller was in APP mode, sending GAID will reset it back into PTCH. 

    The other reset command (Gaid, warm reset) resets the PD controller back into its original configuration that was loaded and the PD will remain in APP mode. 

  • 0 in reply to Raymond Lin
    Prodigy 70 points

     Do you have any examples of how to use Gaid? Also, the issue we are trying to solve is failure modes when downloading patch bundle. Will Gaid help resetting the part back to PTCH allowing us to restart the process?

  • 0 in reply to Nihir Kumar
    TI__Mastermind 34436 points

    Hi Nihir, 

    Gaid (Warm Reset) will only reset the PD back to the original config (MODE is still in APP).

    GAID (Cold Reset) will reset the PD back to its ROM code (MODE is in PTCH).

    If you want to reset the PD back into PTCH mode you should use GAID in this scenario. 

    Thanks and Regards,

    Raymond Lin