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

DRA75P: VAYU EVM - Power good net

AClemotte
Expert 1060 points
Part Number: DRA75P
Other Parts Discussed in Thread: TPS51200, DRA77P

Hi,

We have built a PCB based on the DRA77P. We have made the power supply for the RAM based on the VAYU EVM PCB: the TPS77112 and the TPS51200. We have built a network of power good that controls the PORz. This network includes:

  • PMIC O917A154TRGZTQ1 RESET_OUT,
  • power good of the TPS57112,
  • power good of the TPS51200DRCRG4 and
  • power good of a regulator that feeds the VDDSHV2 to 1V8 (recently added after this post:

We are currently seeing a very strange behavior: when making an attempt to update the system (android) through USB3.0, the net of power good, which controls the PORZ, drops unexpectedly. From the SW side there is no trace as it is a HW reset. The problem has been solved after removing the power good of the TPS57112 and the TPS51200DRCRG4 from the general power good net. We have done this since we have seen that the VAYU EVM does not include the power good of the TPS57112 and the TPS51200DRCRG4 to the line that controls the PORZ.

The problem we have has been solved, however we do not understand why and we are not sure that it is a correct solution.

The questions:

  1. Who should control the PORz? Our criteria has been: release the PORz after all supplies reach valid operating levels.
  2. What is the relationship between the power good of the TPS57112 and the USB3.0? Is it possible that the TPS57112 drops the power good due to a high current requirement when trying to update the SW?


Greetings,

  • 0
    Expert 1060 points

    Hi, do you have any news about this topic? Regards

  • 0
    TI__Intellectual 1671 points

    Hi please see response below,

    >>>The problem we have has been solved, however we do not understand why and we are not sure that it is a correct solution.

    >>>The questions:

    1. Who should control the PORz? Our criteria has been: release the PORz after all supplies reach valid operating levels.

      [AJS]: Your PORz criteria is correct. PORz should be released after all power supplies are at valid operating levels and the power up sequence is finished. In the case of the EVM, PORz is controlled by the PMIC since that is where the last power supplies would be in the power sequence. For power sequence tables please refer to the DM for the SoC. In this case of the customer design, ideally all power devices would likely need to be monitored so the AND'ing of PGOOD signals seems to be OK. 

    2. What is the relationship between the power good of the TPS57112 and the USB3.0? Is it possible that the TPS57112 drops the power good due to a high current requirement when trying to update the SW?

      [AJS]: Has the EN to these devices been probed during the SW update process? It is possible the Software update could be doing something with the PMIC causing a REGEN signal being sent to the DDR power devices? The TPS57112 device has a 2A current limit. Could it be possible the DDR pulls too much current during this process causing the PGOOD to dip?

    Thanks,

    Alec



  • 0 in reply to AJS214
    Expert 1060 points

    Hi Alec,

    1. Who should control the PORz? Our criteria has been: release the PORz after all supplies reach valid operating levels.

      [AJS]: Your PORz criteria is correct. PORz should be released after all power supplies are at valid operating levels and the power up sequence is finished. In the case of the EVM, PORz is controlled by the PMIC since that is where the last power supplies would be in the power sequence. For power sequence tables please refer to the DM for the SoC. In this case of the customer design, ideally all power devices would likely need to be monitored so the AND'ing of PGOOD signals seems to be OK.
      [ACM] Yes, PMIC_RESET_OUT is the last signal to go to a "valid" state. However, in addition to the boot circumstance where the PORZ must be released when all the sources reach a correct value, there is another circumstance: the PORZ must go to an invalid value if any of the sources have problems, right? For example if the TPS57112 (RAM power supply) has some kind of problem, this chip will not be able to pull down the PORZ since it is not connected to it in the EVM. Why in the EVM the power good of the TPS57112 is not in the line of PORZ? And the TPS51200?

    2. What is the relationship between the power good of the TPS57112 and the USB3.0? Is it possible that the TPS57112 drops the power good due to a high current requirement when trying to update the SW?

      [AJS]: Has the EN to these devices been probed during the SW update process? It is possible the Software update could be doing something with the PMIC causing a REGEN signal being sent to the DDR power devices? The TPS57112 device has a 2A current limit. Could it be possible the DDR pulls too much current during this process causing the PGOOD to dip?

      [ACM] I have not verified if the REGEN_DDR signal drops, I try to do the measurement as soon as possible. But since the problem has been "solved" after removing the power good of the TPS51200 and TPS57112 from the PORZ control network, it is clear that one of these two chips has some kind of problem and is notifying it through its power good pin. So I do not understand why this possible situation is ignored in the EVM removing these two power good from the PORZ control line. I try to also measure which of the two chips is pulling the PORZ down, if the TPS57112 or the TPS51200.

    Regards,

  • 0 in reply to AClemotte
    TI__Intellectual 1671 points

    Hi AClemotte,

    It will be good to see the scope shots to determine if the EN of these devices is going low OR if the PG is being tripped on the output voltage/current limit. It is hard to tell what is actually causing this event to happen without visual evidence.

    To answer your question about the EVM, the EVM is not designed for every application and in this instance the EVM designers at the time made the decision to monitor other certain PG signals. 

    I look forward to seeing the scope images.

    Thanks,

    Alec