On Wednesday, 29 April 2015 20:18:51 UTC+2, Andrew Bradford wrote: > > If you take a BBW and cut the trace coming from U8 pin 5 (the LDO enable > line) and then wire U8 pin 5 to the PWR_LED net on page 2 of the > schematic, then the U8 LDO will shutdown correctly when on battery. >
It will shut down. It will however not shut down *correctly*, neither on battery nor on dc power. So, the BBW has a slightly different power scheme, including a different variant of the PMIC which affects timing and use of strobes. For reference, the relevant changes are: - strobe 15: LDO1 (rtc) and - strobe 1: DCDC1 (vdds, 1v8, ddr) - [5 ms delay] - strobe 2: LDO2 (power led) - strobe 3: LDO3 (3v3a, enables 3v3exp) - strobe 4: LDO4 (3v3b) This works for boot, and it may have been okay for shutdown if strobe 3 directly controlled 3v3exp (some other TI PMICs have GPIOs in the power sequence for such purposes), though it'd still make me slightly nervous and I would have preferred a later strobe. Using 3v3b to enable 3v3exp would certainly have made more sense to me than 3v3a, and I think has a decent chance of working correctly. In all cases it would be highly desirable to have the 3v3exp actively discharged when disabled like the PMIC LDOs do, but neither the BBW 3v3exp regulator nor the BBB 3v3b regulator does this. This means that even if they are shutdown before the 3v3a, their output rails may not discharge quickly enough and still end up getting (partially) discharged via processor IOs when the 3v3a shuts down. This is of course highly dependent on CAPE(s) present (if any), especially on the BBW. Moving the enable to strobe 2 as you're suggesting however means that 3v3exp gets powered up a full milisecond before the 3v3a at boot. Any pins driven or strongly pulled high to 3v3exp by an external CAPE will heavily leak to the 3v3a through processor IOs. During shutdown the same thing happens again, plus some remaining discharge after the 3v3exp is disabled. This is not good for the long-term health of the processor. This fix was incorporated into BBB but apparently there are other problems, > too. > It was incorporated into BBB, and then undone in rev A6 for exactly the reason stated above. Unfortunately, instead of actually fixing the problem they reverted to using the 3v3a as enable-signal, even though the early posts in this thread show they knew about the problems this causes for battery-powered operation (though maybe they forgot). To make matters worse, while the BBW needs a CAPE to trigger the problem since the 3v3exp is used exclusively for those, on the BBB the 3v3b and 3v3exp have been merged and the on-board peripherals powered by it already get the job done. Matthijs -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
