• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Answers 2 answers
  • Subscribers 64 subscribers
  • Views 323 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.

TPS6521825: Variability in preprogrammed delays

adevries
Intellectual 945 points
Part Number: TPS6521825
Other Parts Discussed in Thread: TIDA-050038, TPS6521815

Hello TI Forum,

I have a circuit that utilizes the TIDA-050038 reference design. This design uses a TPS6521825 and LP873347 PMIC to provide power to an i.MX 8M mini processor. This reference design has the TPS PMIC generate the 3.3V rail, and feeds that rail to the input of LDO0 on the LP PMIC; LDO0 then generates a 1.2V rail.


Based on the preprogrammed delays in each of these PMICs, the 3.3V and 1.2V rail are supposed to come up at the same time: the TPS PMIC enables the LP PMIC, waits 12 ms, then enables the 3.3V rail, meanwhile, the LP PMIC gets enabled, waits 12 ms, then enables the 1.2V rail. So in theory, both rails should turn on at the same time; however, in practice, this is not always the case.


I have a quantity of 13 identical CCAs, and 2 of these boards have an issue where the 3.3V rail takes too long to turn on and sends the board into a fault state. The other 11 CCAs function correctly. To illustrate the issue, I am attaching a couple photos: one where the CCA turns on correctly, and one where the CCA enters a fault state. In both oscilloscope captures, I measured the time it takes from the TPS PMIC enabling the LP PMIC to the 3.3V rail turning on. On the board that is faulty, the 3.3V rail takes about 12.36 ms to start turning on the 3.3V rail. Shortly after that, you see the 1.2V rail attempt to turn on. At this point, the 3.3V rail is not high enough to allow the 1.2V rail to fully turn on. 1 ms later, the LP PMIC measures the 1.2V rail, sees that it is below the short-circuit threshold, and triggers a fault because it thinks there is a short circuit on the 1.2V rail.  On the functional board, the 3.3V rail turns on approximately 11.5 ms after the LP PMIC is enabled. About 700 us later, the 1.2V rail attempts to turn on and is successful because the 3.3V rail is high enough.


So, the source of this fault appears to be the TPS PMIC taking too long to enable the 3.3V rail. Is there anything I can do to shorten this delay? The TI reference design also appears vulnerable to this fault. When it was being designed, was this issue encountered? If so, how was it handled in that case? Since the delay is burned into the TPS IC, I'm not sure what modifications I can make to fix this issue.

 

  • 0
    TI__Mastermind 19080 points

    Hi adevries,

    It looks like there was a workaround block diagram attached to the thread that might be used to delay the LP enable signal. This might be something to consider since it appears that you would only require a small additional delay to allow LDO0 to ramp up without a fault: TIDA-050038_Revised_RESET_scheme.pdf

    The datasheet doesn't have any specifications for the delay accuracy which means this information is unavailable at this time. However, from the thread above it sounds like this issue with LDO0 on the LP turning on too early is previously encountered situation.

    Can you check what your default setting for REG23 is on the TPS6521825? What data do you read from the register on initial power up?

    Regards,

    James

  • 0 in reply to James Steenbock
    Intellectual 945 points

    Hi James,

    Thanks for the reply. Unfortunately, I cannot access the E2E thread you linked. It looks like maybe it's on an internal forum? I was able to look at the revised reset scheme pdf and it's helpful to see how other people have fixed this issue.

    The default setting for register 0x23 on the TPS PMIC is 0x8a. I realized after I wrote this initial post that the 3.3V rail is supposed to turn on at strobe 10, which is a 10ms delay from strobe 5 and the LP PMIC being enabled. So my initial post that talks about both 1.2V and 3.3V rails having a 12ms delay is incorrect. The 1.2V has a 12ms delay, and the 3.3V rail should have a 10ms delay, except it's more like 12ms (which causes the issue).

  • +1 in reply to adevries
    TI__Mastermind 19080 points

    Hi adevries,

    To summarize the information I was trying to share with you since access is restricted:

    • Changing REG23 to a value of 0x89 was the software workaround for this issue in the past. In this case, if you are able to access I2C on the affected device you can reprogram REG23 with a value of 0x89 which will turn on DCDC3 at STROBE9. Since DCDC3 is being sequenced 2ms earlier, the output voltage from DCDC3 should be ramped up by the time LDO0 is activated. From your scope capture, 2ms should be enough to fix the problematic boards.

    • The other option was the hardware solution described in the PDF I attached before. This may be necessary if you cannot access I2C because the LDO0 issue appears at the very first power up of the board

    Regards,

    James

  • 0 in reply to James Steenbock
    Intellectual 945 points

    Hi James,

    Thanks for the summary from that thread. Out of curiosity, did that thread (or any other information you came across) explain why the 3.3V rail is so delayed?

    The datasheet for this PMIC mentions, " If a rail takes longer than the strobe delay time to power up, the next rail will wait for the previous rail to reach its PGOOD voltage, and then may wait an additional 1 ms until it is enabled". Based on this statement, I was looking at other rails that come up before the 3.3V rail and noticed that, on my board, the 1.8V rail starts coming up on strobe 8 (which is correct), but it takes about 4ms to fully rise. I'm wondering if this long rise time causes an extra delay before strobe 9 and leads to strobe 10 also being delayed.

    I tried removing about 20% of the capacitance I have on the 1.8V rail, but the rise time didn't appear to change at all. When DCDC4 (the 1.8V rail) turns on, does it rise at a set slew rate? Or can I make it rise faster by removing capacitance?

  • 0 in reply to adevries
    TI__Mastermind 19080 points

    Hi adevries,

    The DCDC4 output steps up at a set rate that isn't directly related to the external components. We have a SLEW register (REG1A) but this register should only affects DCDC1 and DCDC2.

    Check the DCDC2 enable timing to see if additional delay is being added to STROBE9.

    I can do the same on one of our EVMs and see what I find.

    Regards,

    James 

  • 0 in reply to James Steenbock
    Intellectual 945 points

    Hi James,

    Good catch! I forgot there is indeed a voltage rail on strobe 9. I measured how long it took to come up, and it was exactly as I guessed: DCDC2 is delayed coming up because DCDC4 doesn't come up fast enough. It's supposed to come up 2ms after DCDC4, but it's actually about double that.

    So, in the end, this seems to be an issue with the behavior of the TPS PMIC. Do you know if TI would consider releasing a variant of this PMIC with updated programming to fix this?

  • 0 in reply to adevries
    TI__Mastermind 19080 points

    Hi adevries,

    Since no variant was made when this was brought up in the past thread I mentioned, it is unlikely that there will be a variant released now, especially given that there is both a software and hardware workaround available. We would need a large business case justification to go through the release process.

    I see the same 4ms rise time on our EVM so this doesn't appear to be an issue with your system specifically. However, the best course of action would still be one of the options I listed above in my previous post, if for no other reason than expediency.

    Regards,

    James

  • 0 in reply to James Steenbock
    Intellectual 945 points

    Hi James,

    That's unfortunate for me, but I appreciate the honesty.

    Do you think TI should draw attention to this potential issue by including a note or something in the TPS6521825 or LP873347 PMIC datasheet? Or a note on the  TIDA-050038 schematic? Hopefully we can help others avoid encountering this known issue.

    I was (obviously) not aware of this issue when I designed the CCAs that now have this problem, and so I now have a quantity of assembled CCAs I need to fix with a modification of some kind. Is it possible to order a batch of TPS65218XX or LP8733XX PMICs with custom programming? Or order an unprogrammed version we can program ourselves?

    Also, in your research into this issue, have you found anything that would suggest environmental changes can make this issue appear or disappear? In other words, if I test a CCA and it turns on fine, is it safe to assume it would continue to work across temperature/humidity/etc.? Or is it possible this issue can appear later? I'm just trying to figure out how tainted these CCAs are.

  • 0 in reply to adevries
    TI__Mastermind 19080 points

    Hi adevries,

    adevries said:
    Do you think TI should draw attention to this potential issue by including a note or something in the TPS6521825 or LP873347 PMIC datasheet? Or a note on the  TIDA-050038 schematic? Hopefully we can help others avoid encountering this known issue.

    Adding a note to our provided documentation is something that we would need to discuss internally so I can't promise anything specific at this time. However, updating documents is far more likely than releasing a whole new device spin so I will definitely add this issue to our list of potential updates.

    adevries said:
    Is it possible to order a batch of TPS65218XX or LP8733XX PMICs with custom programming? Or order an unprogrammed version we can program ourselves?

    The TPS6521815 is a user-programmable version of the PMIC you are currently using. Ordering a version that is custom programmed beforehand would require a business case submission with our sales or marketing team but ordering the TPS6521815 would be faster if you are able to program the settings.

    adevries said:
    Also, in your research into this issue, have you found anything that would suggest environmental changes can make this issue appear or disappear? In other words, if I test a CCA and it turns on fine, is it safe to assume it would continue to work across temperature/humidity/etc.? Or is it possible this issue can appear later? I'm just trying to figure out how tainted these CCAs are.

    I have not seen a temperature component to this issue but extensive testing on this specific situation has not been conducted. Overall, the device is characterized across a –40°C to +105°C temperature range but I usually recommend moving away from potential edge cases if a fix is available.

    Regards,

    James

  • 0 in reply to James Steenbock
    Intellectual 945 points

    Hi James,

    Only after reading the TPS6521815 datasheet did I realize the power-up settings were stored in EEPROM, not OTP memory. This is much better news for me! It should definitely be possible to change register 0x23 to 0x89 and commit that to EEPROM memory, and that's far easier than trying to modify these boards.

    I think I assumed that the LP PMIC and TPS PMIC stored their power-up settings the same way, but that's not the case!

    James Steenbock said:
    I have not seen a temperature component to this issue but extensive testing on this specific situation has not been conducted. Overall, the device is characterized across a –40°C to +105°C temperature range but I usually recommend moving away from potential edge cases if a fix is available.

    Agreed, we are going to apply this fix to all the CCAs, regardless of if they exhibit this behavior or not.

    James Steenbock said:
    Adding a note to our provided documentation is something that we would need to discuss internally so I can't promise anything specific at this time. However, updating documents is far more likely than releasing a whole new device spin so I will definitely add this issue to our list of potential updates.

    Thank you for taking note of this and potentially updating the datasheet. While you're adding items to the list of potential updates, I found 2 additional things you may want to consider updating.

    1. In section 8.5.1, "Programming Power-Up Default Values", it says, "A consecutive write of 0x50, 0x1A, or 0xCE to the password register commits the current register settings...". I believe that should be changed to say "A consecutive write of 0x50, 0x1A, and 0xCE"

    2. According to Table 8-8, CHIPID Register Field Descriptions, a TPS6521825 should have the value 0x45 here. However, on all of the TPS6521825 PMICs I've looked at, that register reads as 0x25.

    Neither of these are huge deals, just wanted to pass along the two things I noticed.

    Thank you very much for your help with all this, I really appreciate it. Quality support like this makes me happy to use TI parts.

  • 0 in reply to adevries
    TI__Mastermind 19080 points

    Hi adevries,

    Thank you for the additional information and if you have any other questions, let us know here on E2E!

    Regards,

    James