VDD_3V3B regulator latched on by leakage, battery pins unsafe to use as result

[mvduin]

The BBB has three 3.3V supply rails:

• VDD_3V3AUX from PMIC LDO3 (100 mA) is only used for the power led
• VDD_3V3A from PMIC LDO4 (400 mA) is used for the AM335x 3.3V I/O supplies and a few miscellaneous on-board uses
• VDD_3V3B from discrete LDO U4 (500 mA) is available on P9 for external hardware and also used for various on-board uses such as eMMC, μSD card, ethernet phy, and the console uart buffer.

Since 3V3B is used to drive signals into the AM335x, it is critical this supply comes up after (or simultaneous with) 3V3A. The BBB attempts to ensure this by simply using 3V3A as enable-signal for 3V3B, which has the desired result during power-up. During power-down however a problem arises: current injected from 3V3B into AM335x I/Os flows leaks back onto 3V3A (via protection diodes inside the AM335x) which causes 3V3A to remain high enough to keep 3V3B permanently enabled as long as SYS_5V continues to supply LDO U4.

The impact is easily visible in a scope capture of the power-off sequence:

• t = 0 ms: PMIC starts power-off sequence by deasserting PGOOD and (bizarrely) cutting power to SYS_5V, which means the system is now running on capacitors only
• t = 2 ms: DCDC2 and DCDC3 supplying VDD_MPU and VDD_CORE respectively (not depicted) are shut off
• t = 3 ms: LDO4 supplying VDD_3V3A is shut off, but VDD_3V3B remains on
• t = 4 ms: LDO2 supplying VDD_3V3AUX (not depicted) is shut off, SYS_5V has fallen to 3.5V and VDD_3V3B is starting to track SYS_5V - 0.1V
• t = 9 ms: LDO3 supplying VDD_1V8 is shut off
• t = 10 ms: DCDC1 supplying VDDS_DDR (not depicted) is shut off
• t = 11 ms: LDO1 supplying VRTC (not depicted) is shut off and LDO_PGOOD is deasserted, finishing the PMIC's power-off sequence
• t = 20 ms (approx): LDO U4 supplying VDD_3V3B finally shuts off

As a result, the absolute maximum ratings of the AM335x (max I/O voltage = supply voltage + 0.3v) are violated for about 15 ms on each power-off. Whether this has any long-term reliability impact in practice is unclear.

A far more serious situation occurs when the PMIC battery terminals are used to power the system, in which case SYS_5V is always-on and as a result LDO U4 never shuts off at all:

In this state there's about 35 mA continuously flowing from 3V3B into the AM335x (and back out to 3V3A) via pull-ups on about two dozen pins. However if one makes the mistake of having a serial console cable connected during this, the console uart buffer (powered from 3V3B) drives 45 mA of current into UART0_RXD, causing 3V3A to be raised more than 2V above the 1.8V supplies, a situation the am335x datasheet repeatedly and emphatically warns must be avoided under all circumstances. Yikes.

Note that this is actually an ancient issue dating all the way back to the BeagleBone White (discussion thread), whose LDO U8 supplying VDD_3V3EXP suffered from the same problem, except it had no on-board leakage paths into AM335x I/O like the BBB does (but external hardware powered from VDD_3V3EXP easily creates such paths obviously). It also affects the OSD335x whose power scheme was copy-pasted from the BBB.

[mvduin]

Possible fixes:

• Use a tracking voltage regulator for VDD_3V3B that tracks the voltage of VDD_3V3A.
• Use PGOOD as enable-signal for the 3V3B. The only caveat here is that this is an 1.8V signal while the V_IH(min) of the TL5209's enable input is 2V, so this signal would need to be buffered / level-shifted to 3.3V or a different LDO needs to be used which does accept an 1.8V enable-signal.
• Reprogram the PMIC to enable LDO2 (VDD_3V3AUX) after or at the same time as LDO4 (VDD_3V3A) and use LDO2 as enable-signal for the 3V3B. This option appears very annoying since changing the non-volatile programming of the TPS65217 (assuming the procedure documented in section 7.6.1.1 of the TPS652170 datasheet applies to all TPS65217 family members) requires applying 8V to its PWR_EN pin.
• Especially for new designs, consider replacing the TPS65217 by the TPS65218D0, which supplies 3.3V using a buck-boost converter which can supply 1.6A output hence eliminates the need for a separate discrete 3.3V LDO. This also greatly improves energy efficiency, and it can provide stable 3.3V output even if the system is supplied directly by a nearly-depleted Li-Ion battery, albeit with reduced output current (down to 1A 3.3V output from 2.8V input).

Workarounds:

• if your power requirements on 3.3V are modest enough, replace LDO U4 by a patch wire.

[sslupsky]

This is probably quite an important issue to resolve since the demise of Andicelabs. Andicelabs had a power cape with a separate battery power path and it worked reasonably well. However, for quite a while now that cape is no longer available so we have to resort back to the PMIC battery pins.

[jadonk]

I believe Andice was looking to open source their design such that we could invite another manufacturer. I will follow-up.

[sslupsky]

@jadonk Yeah, I asked him about that on his GitHub repo but he never responded.

[Ixanom]

BTW Figure 25 in the SRM document still shows the EN pin of U4 wired to VDD_3v3AUX rail. That's misleading.

Also it's interesting, in the section 5.4, external LDO TLV70233 is mentioned. In that LDO, the hysteresis window for EN input is relatively narrow. So in theory, it would be practical to implement a quick and dirty fix using just a voltage divider of two resistors on that pin. And that LDO optionally has internal discharging capability for Vout. For some reason, they'd decided to substitute that part with TL5209, which seems less suitable here, imho...

[apper002]

Having several BBB with Roboticscape flying my pretty expensive stuff...
Does this setup, with only the Cape being powered by the Jack with 3S Lipo prevent these issues??
Any ideas or help would be much appreciated!

[mvduin]

This issue is about the BBB's own battery pins (1S), which are not normally accessible by capes (it's an unplaced header). The robotics cape simply provides the BBB with 5V.

[apper002]

Got it, ThX