Enhancement request: let's measure the battery voltage
Opened this issue · 6 comments
BBB design uses the PMIC which is extremely suitable for a battery powered applications. In such applications, it's essential for the SW to be aware of the battery voltage. The PMIC integrates analog multiplexer, that can provide this information. In the BeagleBone design, the multiplexer's output (MUX_OUT pin) is routed to AN7 input of the processor and this is fine.
For some reason, in the BBB design that feature is broken and the MUX_OUT pin is left not connected. So the customers wishing to get it back having to exercise their soldering skills. Because of the PMIC part dimensions, it's a bit difficult to solder a wire to the MUX_OUT pin manually.
If it's a problem to completely fix the PCB routing in the future revision, I'd like to propose to implement a workaround in the form of test point via on the PCB somewhere near the MUX_OUT pin of the PMIC. That will simplify the soldering work.
Hmm, I do wonder why this change was made. My initial thought was that there might be a concern with the PMIC driving the analog inputs of the AM335x when it's powered off, but when the PMIC goes into OFF state it resets all registers which includes setting the mux back to default (high-Z) so that shouldn't be a problem.
BTW, be cautioned: using the battery terminals of the BBB is not officially supported and not advisable. A quirk of the TPS65217 PMIC is that SYS_5V remains at battery voltage even when the board is powered off. Pull-up resistors on various I/Os cause current from VDD_3V3B to be injected into processor pins back onto VDD_3V3A, which is used as enable-signal for the VDD_3V3B regulator, causing it to never shut down hence causing this current leakage to persist. At the very least this causes significant battery drain even when powered off, but if any AM335x I/O pins are strongly driven high from VDD_3V3B, e.g. by external hardware on the expansion headers or by the on-board serial console buffer (when a serial cable is attached), then this will seriously violate the absolute maximum ratings and potentially damage the AM335x.
See issue #11 and also https://elinux.org/BeagleBone_Power_Management#Battery and the discussion thread it links to.
When I'd encountered the 3V3B problem for the first time, I googled a little in the course of investigation and have found all the discussions. Seems it's a well known problem so it must be known to the designers for years. Moreover the BBB is by no mean a new design so it must be reviewed with TI more than once. I was sure that by now it's free from a HW defects of such severity. Recently, the new PCB version has emerged but still with no fix. No idea why it's so poor.
Anyway for the time being every new customer have to do the mandatory homework before starting using the board. To fix the problem, I opted to populate my boards with piggybacked voltage monitor (see the image). It's STM1061, which was suggested in the discussions. The part is easy to source and work just fine.
But now the bottom side of the board is more vulnerable to mechanical damage. Some kind of cover is necessary. So the cover board is built to protect the patchwork. That provides enough room for battery. Nothing special. A battery just completes the fix making BBB a reliable host for any software. A must have with the current PMIC, actually.
And Matthijs, thanks a lot for your efforts in sharing the information!
So this also works with every Cape connected to the BBB?
None of this is related to capes in any way.
That's correct. But does powering the BBB from the Cape and not BBB 5V jack influence this...
No, the pins used to power a BBB from a cape (P9.05/06) are tied directly to the 5V jack, so which of the two is used to supply the BBB is completely indistinguishable to the BBB.