BeagleBone Power Management
Work in progress: plan is to first collect the raw info, then organize and add prose.
|Warning:||Supplying power via the battery terminals is experimental and not officially supported. The same is true for entering the SLEEP state of the PMIC on shutdown, aka "RTC-only mode". Doing either causes vsys to remain supplied after shutdown, triggers the 3v3 regulator bug afflicting most BeagleBone versions, and may cause hardware damage.|
Also, keep in mind that a Li-ion battery only has a nominal voltage of 3.6-3.7 V which may render the USB host port unusable and cause 3.3V supplies to lose regulation if too much current is drawn or the battery has insufficient charge left.
Entering RTC-only mode will fail entirely on the BeagleBone White for multiple reasons. On the BeagleBone Black, if LDO1 is connected to vdds (Black A6A and later, also Green) then major leakage current from vdds to the 3.3V supplies occurs during shutdown and will continue to flow if RTC-only mode is entered. This can be avoided by removing R8 and reinstalling R9 instead (against TI's advice), but you would also still need to deal with the 3v3 regulator problem.
Power path and charger
The BeagleBone, though its TPS65217 PMIC, can draw power from three sources (in descending order of preference):
- The 5V DC supply via barrel jack or pins 5 and 6 of connector P9,
- USB bus power (5V) via its mini-B (device) port,
- a standard (3.6/3.7V) Lithium-ion rechargeable battery via unplaced header (TP5-8).
Confusingly, the main 5V DC supply input is called "AC" by the PMIC docs (no, it doesn't tolerate AC input) and "vdd_5v" by BBB docs. The USB input behaves the same as the DC input except for current-limiting options, and will usually not be mentioned explicitly. Apparently the PMIC will only draw power from one of the two 5V inputs at any given time. However, if a battery is also present, it can supplement the DC input when needed (e.g. due to input current limiting). This will obviously cause the power path output (vsys) to drop down to battery level.
The battery is considered valid ("vbat ok" in table below) when at least 3.3 V, even though the 3.3 V supplies obviously can't be well-regulated at such low voltage.
Relevant voltage thresholds and limits for DC input:
|Absolute maximum||20 V|
|Overvoltage protection kicks in||5.8 – 6.4 V (6 V typ)|
|Minimum to charge battery||4.3 V|
|Minimum to power up||vbat not ok||4.3 V|
|Minimum to stay on||3.5 V|
|Switch from BAT to DC||vbat ok||vbat + 190 mV|
|Switch from DC to BAT||vbat + 125 mV|
The output of the power path is called vsys or sys_5v, although it will obviously be lower than 5 V when on battery power. It is directly available on pins 7 and 8 of connector P9, and used for:
- all regulated supplies
- the four user LEDs
- "5V" on the μHDMI port ("protected" by an RXEF010 PTC)
- "5V" on the USB host port (protected and switchable by U8, a TPS2051)
When the system is off (but some power is available), the PMIC ties vsys to vbat regardless of whether a battery is present or not.
If no valid battery supply is available, the DC supply must ramp up sufficiently rapidly (within 50 ms) to trigger power-up. Otherwise, the PMIC enters some kind of lockup state. The same lockup state has been reported to occur as a result of brief (< 10 ms) interruptions of the DC supply. It appears the presence of valid vbat both prevents and resolves this lockup state.
|BBone White (TPS65217B)||BBone Black (TPS65217C)|
|LDO1||1.8 V||100 mA||vrtc||LDO1||1.8 V||100 mA||vrtc|
|DCDC1||1.8 V||1200 mA||ddr||DCDC1||1.5 V / 1.35 V||1200 mA||ddr|
|1v8||LDO3||1.8 V||400 mA||1v8|
|LDO2||3.3 V||100 mA||pwr_led||LDO2||3.3 V||100 mA||3v3aux|
|LDO3||3.3 V||200 mA||3v3a||LDO4||3.3 V||400 mA||3v3a|
|LDO4||3.3 V||200 mA||3v3b||U4||3.3 V||500 mA||3v3b|
|U8||3.3 V||1000 mA||3v3exp||3v3exp|
|DCDC2||1.1 V - 1.285 V||1200 mA||vdd_mpu||DCDC2||1.1 V - 1.325 V||1200 mA||vdd_mpu|
|DCDC3||1.1 V - 1.125 V||1200 mA||vdd_core||DCDC3||1.1 V - 1.125 V||1200 mA||vdd_core|
Note 1: The TPS65217C configures DCDC1 at 1.5V by default (for DDR3). The ram used on the Black also supports DDR3L, hence DCDC1 is changed to 1.35V by software (before ram is released from reset) to reduce power consumption.
Note 2: Initial DCDC2/3 voltage levels are 1.1V. They are dynamically changed by software for maximum performance.
The White has four 3.3V supply rails: the pmic provides pwr_led (ldo2), vdd_3v3a (ldo3), and vdd_3v3b (ldo4), while a separate regulator (U8, TPS73701) provides vdd_3v3exp which is the 3.3V supply provided on expansion connector P9. The 3v3a supply is used as enable-signal for the 3v3exp-regulator.
On the Black, vdd_3v3a is provided by ldo4 while a separate regulator (U4, TL5209) provides vdd_3v3b, which also serves the role of vdd_3v3exp. The rail supplied by ldo2 was renamed vdd_3v3aux, since initially the Black also used it as enable-signal for the 3v3b-regulator. Since rev A6 the 3v3a is used as enable-signal and ldo2 only drives the power led (same as the White).
The main uses of the 3v3a are:
- all am335x 3.3V supplies (vddhv1-6, vdda3p3v_usb0-1)
- pull-ups for r̅e̅s̅e̅t̅, I²C 0 bus, and sysboot configuration
- (White only) μSD card and pull-ups on associated I/Os (except for card-detect)
The Black additionally uses the 3v3a for a miscellaneous bunch of minor consumers:
- pull-ups for two irq lines: p̅m̅i̅c̅_̅i̅n̅t̅, u̅s̅b̅1̅_̅o̅c̅
- board identification EEPROM
- clock generators U6 and Y4 for HDMI CEC and audio respectively
- open-drain inverter U3 for eMMC reset (unused)
Oddly, the White also uses the 3v3a (rather than vrtc) for the pmic's "vio" supply used for its ldo_pgood and pgood outputs. A voltage divider is therefore used to connect ldo_pgood to the r̅t̅c̅_̅p̅o̅r̅ input of the am335x. (As a side-effect, attempting to enter RTC-only sleep on a White will cause it to wake up again immediately due to r̅t̅c̅_̅p̅o̅r̅ going low.)
All remaining on-board 3.3V supply needs are provided for by 3v3b.
Considerations for external connections
Most pins on the expansion headers are directly connected to processor I/O pins, which are supplied by the 3v3a (for drivers, pull-ups, and protection diodes). While power-on reset is asserted (p̅o̅r̅ low) these are never driven by the processor but have a (weak) pull-up/down enabled (default pull-direction varies per pin). External hardware must refrain from driving these pins unless the 3v3a has stable power. Unfortunately, neither the 3v3a nor p̅o̅r̅ is available on the expansion headers, however the following relationships can be used:
- if 3v3a is not powered, p̅o̅r̅ will be low;
- if p̅o̅r̅ is low, r̅e̅s̅e̅t̅ will be low (since BBB rev A6) or pulled to 3v3a (before)
- if 3v3a is powered, 3v3exp will also be powered.
Therefore external hardware can abide by the rules by
- accepting the possibility that pins may be driven by the processor when 3v3exp is powered, and
- refraining from driving processor pins when 3v3exp is unpowered or r̅e̅s̅e̅t̅ is low.
These criteria are met for example by powering logic from 3v3exp but making sure its drivers are disabled while r̅e̅s̅e̅t̅ is low.
Some pins have special considerations:
- The power-button signal (P9.09) is weakly pulled up to a pmic-internal supply (typ ~4.5V). It is intended to be connected to a power button on a physical user interface (if any). It has the rather unique property that its voltage can exceed that of all other pins on the expansion headers (e.g. when in OFF-mode while powered via USB).
- The ADC supply (P9.32) is 1.8V and the ADC inputs (P9.33, P9.35-40) must never exceed it.
- Most "inputs" can actually also be driven high and/or low (varies per pin), used e.g. for resistive touchscreens.
- Be sure to read advisory 1.0.32 of the AM335x errata carefully before making any low-impedance connections to these pins! Oddly, although it seems to me the erratum could cause vdd_adc to be shorted to ground, it claims no workaround is needed (and none is implemented on the BBones) when vrefp=vdd, vrefn=vss, and only moderate-impedance connections are made to the inputs (e.g. a resistive touchscreen).
- The LCD data pins (P8.31-46) are sampled at power-on reset (i.e. when pgood goes high) to determine the boot configuration (sysboot 0-15). Unlike other processor I/Os, their internal pull-up/down is disabled by default, and external 100K resistors to 3v3a or ground are used to ensure correct configuration:
- 01 00 0000 00 0 10111 -- BBW (boot order: mmc 0 (μSD), spi, uart, usb)
- 01 00 0000 00 1 11100 -- BBB, normal (boot order: mmc 1 (eMMC), mmc 0 (μSD), uart, usb)
- 01 00 0000 00 1 11000 -- BBB, sd-boot (boot order: spi, mmc 0 (μSD), usb, uart)
- The SD-boot button (S2) of the BBB overrides sysboot 2 by pulling it to ground via 100Ω. External hardware must be careful not to disturb these lines during power-on (unless changing the boot configuration is the intended goal of course). They are only sampled at power-on reset (including exit from RTC-only sleep), not at warm reset.
- On the BBB, the eMMC pins (P8.03-06 and P8.20-25) have 10K pull resistors to 3v3b.
Hardware is a BBB rev C patched to have a unified 3v3 rail, no external connections other than power, probes, and console cable.
Two kernels are compared: the one on the right is a standard kernel + device tree which enables the (reset-insensitive) HDMI framer, while the one on the left leaves the HDMI framer in standby (its default state, negligible power consumption). There are other differences, but those should be irrelevant during shutdown, certainly once power-on reset is asserted (pgood low).
Most current consumption is eliminated at the start of the powerdown sequence when pgood goes low, although there's a brief burst shortly afterwards (no idea why). Current ramps down more 2 ms later when the core and mpu supplies are disabled, and drops to negligible once the 3v3 supply is cut. Current temporarily increases again due to vdds leakage until it too is cut.
When the HDMI framer is enabled, its continued current consumption (until 1v8 is cut) is clearly visible.
Same thing, but with the power path being cut by the PMIC at the start of the powerdown sequence, the BeagleBone is now running off its capacitors. In this case it managed to make it without losing regulation at any point, but only barely so. With the HDMI framer enabled the 3v3 and 1v8 supplies receive a premature dent.
The PMIC tries, it really does. In fact, while the 3.3V supplies can't be saved (obviously, with the vsys capacitors charged at a mere 3.4V or so), when not burdened by the HDMI framer it still has 2.4V on vsys by the time the 3v3 is disabled, so it almost certainly would have maintained regulation on the remaining supplies if the vdds leakage hadn't ruined it.
By the time the PMIC intervenes the 3v3 supply has already lost regulation, and it clearly makes no attempt to sequence the remaining supplies but disables them simultaneously. The HDMI kernel actually initially has a gentler slope since that kernel happens to have better power management. The inexplicable sudden steepening of slope that happens there is worrying.