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.

Reply via email to