• State Resolved
  • Replies 8 replies
  • Answers 3 answers
  • Subscribers 21 subscribers
  • Views 300 views
  • Users 0 members are here
Support feedback
Options
Options
Related

TPS53689: Inquiry Regarding TPS53689 Security Features for NIST SP800-193 Compliance

Ryo Sawada
Prodigy 70 points
Part Number: TPS53689


We are currently designing and developing a computer system that uses the TPS53689 and aims to comply with NIST SP800-193 at the system level. We have some questions regarding the security features of the TPS53689:

  1. If user NVM data becomes corrupted, is there a mechanism to detect this error? (For example, CRC or other integrity checks.)
  2. If such an error is detected, how does the device respond? (For example, does it stop power output, automatically restore the data and resume power output, etc.?)
  • 0
    TI__Expert 6205 points

    Hello Sawada-san, 

    Thanks for reaching out. Just to clarify, what exact needs are required from the TPS53689 for NIST SP800-193 compliance? I found the guidelines document, and after briefly going through it I'll attempt to answer the best I can:

    • Yes, we feature both CRC for communications as well as a CRC for the NVM memory that stores configuration data. A fault will be issued if the read CRC does not match the computed CRC of that data during power-on.  
    • A CRC fault detected on power-on will not disable regulation, but a fault will be issued so the host board management controller or host CPU can determine the next action.

    As a side note, if you plan on using the TPS53689, I recommend using the TPS53689T, as we made minor improvements to this device over the non-T variant and while using the same pinout and operation. 

    Kind regards,
    Nick Z

  • 0 in reply to Nick Zahabizadeh
    Prodigy 70 points

    Thank you very much for your response, Nick.
    As for the requirements we expect from the TPS53689, they include detection of data tampering (such as CRC) and an automatic recovery function, if possible.
    Therefore, we would appreciate your additional guidance on the following points:

    • Regarding the statement “I found the guidelines document” mentioned above, could you please provide the specific document name?
    • Concerning “power-on will not disable regulation”, will there be any limitations on protection functions (such as over-temperature, over-voltage, or over-current)?
    • Does the CRC verification cover the entire user data area?
    • When a CRC error occurs and the voltage output is not stopped, will the device operate using default values, or will it continue operating with the erroneous values?
    • Through which interface can notifications be received? (PMBus or SVID?)
    • Is there any recovery function available in response to a CRC error, or is it limited to abnormality notification only?
    • If a recovery function exists, could you please advise on the recommended usage or configuration?
    • Regarding the write-protect feature, could you confirm whether its coverage includes the entire user data area?
    Thank you for your kind cooperation.
    Sawada

  • 0 in reply to Ryo Sawada
    TI__Expert 6205 points

    Hello Sawada-san, 

    My apologies on the delay, we have limited bandwidth due to several team members being out of office of the holidays here in Dallas. I'll be getting to your message in 24 hours. 

    Kind regards,
    Nick Z

  • 0 in reply to Nick Zahabizadeh
    TI__Expert 6205 points

    Hello Sawada-san, 

    Thank you for the patience. I'll be responding to your questions in order:

    • The guidelines for NIST SP 800-193 I'm using are posed by the USA department of commerce at their governmental site here: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-193.pdf 
    • I should clarify there are two different forms of CRC that occur in the TPS536x9 devices:
      • The first is CRC of the user configuration data and "black box" fault recording data. These CRCs are only performed at power-on of the controller, and a fault will be flagged but it does not disable the ability for the output to be enabled and regulated.
      • If enabled, many commands issued via PMBus support a CRC byte to confirm data integrity. If there is a communication CRC failure, a fault is flagged but communication continues without the regulation stopping.  
      • If the controller detects that a command written to it fails the CRC, the controller will NACK. If the user NVM fails the CRC, a fault is flagged but if enabled it will use the values that currently exist in NVM. 
      • Both PMBus and SVID are supported. 
      • A fault related to a CRC failure is only a fault notification.
      • Recovery for faults vary due to the various reasons why the fault might be issued, however generally the board management controller will be performing these commands to attempt power cycling or repeating the communication the controller NACK.  
      • No, write-protect only protects configuration commands. 

    Let me know if you need any clarification. 

    Kind regards,
    Nick Z

  • 0 in reply to Nick Zahabizadeh
    Prodigy 70 points

    Hello Nick,
    Thank you for your response.
    Could you also confirm the following?

    When the CRC of the User Configuration Data is abnormal, is the register set as follows?
    • CMD Code = F2h, MFR_SPECIFIC_F2 (NVM_FAULT_LOG)

    Best regards,
    Sawada

  • +1 in reply to Ryo Sawada
    TI__Expert 6205 points

    Hello Sawada-san, 

    Thanks for your patience, many of us were OOO during the holidays here in the USA. 

    To respond to your question, not exactly. The CRC value store in the last 8 bits of register 0xF2 are used to determine if the user confirmation data located in the rest of the NVM is valid or not. One way of thinking about it is that this CRC is the "golden source" that the computed controller config CRC is compared to.

    At controller power-up if the computed configuration data CRC in the rest of NVM does not match this CRC value in 0xF2 saved at power-down, then the IV BBOX bit in 0xDD will be flagged: 

    Kind regards,
    Nick Z

  • 0 in reply to Nick Zahabizadeh
    Prodigy 70 points

    Hello Nick,

    Thank you very much for your response.
    Thank you for your response.
    No problem at all, and we apologize as well for the delay on our side.

    We have now clarified all the items that needed to be confirmed at this time.
    If we have any additional questions, we will contact you again.

    Thank you for your continued support.
  • 0 in reply to Ryo Sawada
    TI__Expert 6205 points

    Hello Sawada-san, 

    Thank you for the feedback. For future inquiries, please make a new post as it helps our organization of requests. 

    Kind regards,
    Nick Z