-
Notifications
You must be signed in to change notification settings - Fork 201
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
VDD_3V3B regulator latched on by leakage, battery pins unsafe to use as result #11
Comments
Possible fixes:
Workarounds:
|
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. |
I believe Andice was looking to open source their design such that we could invite another manufacturer. I will follow-up. |
@jadonk Yeah, I asked him about that on his GitHub repo but he never responded. |
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... |
Having several BBB with Roboticscape flying my pretty expensive stuff... |
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. |
Got it, ThX |
The BBB has three 3.3V supply rails:
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:
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.
The text was updated successfully, but these errors were encountered: