This is without a cape and it is with the BB Black. That's probably why I was confused about the dates and board versions you referred to.
Brad -----Original Message----- From: Andrew Bradford [mailto:[email protected]] Sent: Thursday, December 19, 2013 8:50 AM To: Brad Andersen Cc: 'Gerald Coley'; [email protected] Subject: Re: [beagleboard] Bone VDD_3V3EXP Disable Issues On 12/19/2013 11:01 AM, Brad Andersen wrote: > The SYS_5V bus has the Battery supply, approx. 3.8V > > > > How can I make sure "all rails are actually turned off via SW"? > > > > I'll go through the procedure and measure all the voltages and report back. Are you running a cape during your tests or not? If so, does your cape have any pull-up resistors on it? Are we talking about white or black bones? I've lost that in this conversation. My original experiments were all with white bones. Thanks, Andrew PS: Please keep me CC'ed, I'm no longer subscribed to the list. > From: Gerald Coley [mailto:[email protected]] > Sent: Thursday, December 19, 2013 7:43 AM > To: Brad Andersen > Cc: [email protected]; Andrew Bradford > Subject: Re: [beagleboard] Bone VDD_3V3EXP Disable Issues > > > > The change only affected when the 3V3B rail was enabled by enabling it > with the 3V3A rail. So, I can't see how they are related. Both LDOs > are powered by the same SYS_5V bus. > > > > What is the level of the SYS_5V bus? > > > > The battery in this case is now supplying all of the LDOs and > switchers. So I am thinking that maybe we need to make sure all rails > are actually tuned off via SW. > > > > Gerald > > > > > > On Thu, Dec 19, 2013 at 9:26 AM, Brad Andersen <[email protected]> wrote: > > Thanks for replying. > > > > Yes I have seen that note. And when the battery is not connected the > VDD_3V3A does shutdown, but not when a battery is connected (A6 version). > When I measure the voltage on VDD_3V3A after the 'shutdown', it is > about 2.4V (it is 3.3V when ON). Is there a path for leakage back to > that node that is keeping the voltage up? > > > > The registers in the PMIC are the same for both board versions. I > have not changed them from what comes with the BBB. > > > > I used this method to test the shutdown: > > Uboot example: > > 1. Boot to the uboot prompt by pressing any key before the kernel boots > 2. Set the PMIC i2c status register to turn OFF when EN line goes down. > (i2c, memory write, device 24, address A, value 0x80) >> i2c mw 24 A 80 > 3. Set the memory base to the RTC registers >> base 44e3e000 > 4. Enable PWR_ENABLE_EN bit (memory write, offset address 98, value in > hex 0x00010000) >> mw 98 10000 > 5. Enable ALARM2 interrupt once (memory write, offset address 48, value > in hex 0x00000010) >> mw 48 10 > 6. Copy over RTC current time to ALARM2 times for hour/day/month/year > (memory copy, from address 8, to address 88, 4 times) >> cp 8 88 4 > 7. This next part is where it gets slightly more complicated because > you are going to manually set the ALARM2 minutes to one or two minutes > after the current time. > > 1. Read the current seconds, minutes. This is easy to manually do > because they are in BCD and not in hex. (memory display, address zero, > 2 > times) >> md 0 2 > 44e3e000: 00000008 00000011 (8 seconds, 11 minutes) > 2. Write to the ALARM2 minutes (seconds should already be zero) (memory > write, address 84, value 0x00000012) >> mw 84 12 (12 minutes) > > 8. Wait until the current time catches up to the ALARM2 time and the > system will power down. If you took too long doing step 7.2 and the > time has already passed, just do step 7.2 again. > > 1. While you're waiting you can keep checking the current time ( this > will show all 6 fields, second, minute, hour, day, month, year) >> md 0 6 > 2. And if you think you have passed your ALARM2 time you can compare > above results with ALARM2 time. If so, go to step 7.2. If you went > onto a new hour, you might have to start from step 6. >> md 80 6 > > Thanks, > > Brad > > > > From: Gerald Coley [mailto:[email protected]] > Sent: Wednesday, December 18, 2013 4:35 PM > To: [email protected] > Cc: [email protected]; Andrew Bradford > Subject: Re: [beagleboard] Bone VDD_3V3EXP Disable Issues > > > > Did you look here? > > > > http://www.elinux.org/Beagleboard:BeagleBoneBlack#Board_Revisions_and_ > Change > s > > > > 3) Moved the enable for the VDD_3V3B regulator to VDD_3V3A rail. > Change was made to reduce the delay between the ramp up of the 3.3V > rails. No evidence of this being an issue, but it really needs to be > as close to the same as possible. > > > > So, you have to shutdown VDD_3V3A to shutdown the VDD_3V3B. > > > > Gerald > > > > > > On Wed, Dec 18, 2013 at 4:38 PM, <[email protected]> wrote: > > I ran into a similar finding on the A6 board. Interestingly, the A5C > works correctly. These are with a battery connected. > > > > I'm investigating a proper shutdown and power-off if the main 5V is removed. > I have a Li-Ion battery connected to keep everything running until a > proper shutdown/power-off can occur. > > Using the method in "Re: [beagleboard] Chip power down and PMIC_POWER_EN" > while in Uboot, I can see that the A5C shuts everything down including > the VDD_3V3B supply (see schematic). The A6 does not. > > > > Now if there is no battery connected, they both power-off. > > > > So what's happening? > > > > Brad > > > > On Thursday, October 25, 2012 2:23:40 PM UTC-7, Andrew Bradford wrote: > > On Thu, 25 Oct 2012 16:13:48 -0500 > > Gerald Coley <[email protected]> wrote: > >> You are correct. This is something we just ran into yesterday and we >> are looking at a solution. The solution is being tested and will not >> be something that shows up in the near future, but hopefully soon. It >> MAY be something that could be done with a wire mod, but it is too >> early to tell. Should know more by Monday. > > Thanks! So I'm not crazy, that's good to know. :) Even if the wire > mod is complex, it'd be great if you could share it. > > >> On Thu, Oct 25, 2012 at 4:07 PM, Andrew Bradford < > >> [email protected]> wrote: >> >>> If I disable LDO3 in the TPS65217, VDD_3V3A should turn off. >>> VDD_3V3A turning off should disable U8 linear regulator causing >>> VDD_3V3EXP to turn off. >>> >>> It doesn't. >>> >>> Disabling LDO3 in the TPS65217 causes VDD_3V3A to drop to >>> approximately 2.4 V. This is not low enough to disable the U8 >>> linear regulator's enable pin. Further, disabling LDO4 after this >>> only causes VDD_3V3A to drop to approximately 1.2 V. Again, this is >>> not enough to disable U8 linear regulator's enable pin. >>> >>> I've tested on an A3 and an A6 bone. >>> >>> I realize there's grave impacts to disabling LDO3 or LDO4, ie: much >>> of the board won't work any more although the ARM core and DDR will >>> still be operating. That's OK for my experiments. >>> >>> How can I turn off VDD_3V3EXP from software without completely >>> turning off all rails on the TPS65217? Is it possible? >>> >>> I'm trying to do this in order to debug an issue we see with a >>> custom cape at power down when running on 3.7 V lithium battery. >>> With our cape attached, VDD_3V3EXP latches on even when the rest of >>> the BeagleBone is powered off. This is due to SYS_5V staying >>> present due to the battery and U8 linear regulator not powering down >>> before the latch action occurs. The TPS65217 and AM3359 are both in >>> the proper states, I can boot due to power button press once in the >>> OFF state (defined by the TPS65217 data sheet). But keeping >>> VDD_3V3EXP running will ruin the battery life while in the OFF >>> state. >>> >>> On the cape, we pull up to VDD_3V3EXP for things like MMC/SD and >>> I2C. I believe this is part of the problem as there may be power >>> back feeding through the pull-ups enough to cause the latch >>> situation. But we believe we're following the recommended pull-up >>> strategy documented in the Bone SRM. >>> >>> Has any one else seen issues like this when attempting to enter the >>> TPS65217 OFF state with capes attached that use pull-ups to >>> VDD_3V3EXP while running on 3.7 V lithium battery power? If so, >>> what capes work? >>> >>> Yes, I realize this is quite a corner case. Sadly, it's an >>> important one for me. >>> >>> Thanks, >>> Andrew >>> >>> -- >>> >>> >>> >> >> > > > > > > -- 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/groups/opt_out.
