Thanks Ash for the unambiguous clarification. Regarding nrespwron, it is still surprising that the PMIC Design-In Guide has explicit language to the contrary- but as long as it is a known-reliable design idiom, I'm happy!

Vikram



On Sat, Mar 2, 2013 at 10:04 AM, <gumstix-users-request@lists.sourceforge.net> wrote:


---------- Forwarded message ----------
From: Ash Charles <ash@gumstix.com>
To: "General mailing list for gumstix users." <gumstix-users@lists.sourceforge.net>
Cc: 
Date: Fri, 1 Mar 2013 22:23:00 -0800
Subject: 
Re: [Gumstix-users]
N_MANUAL_RESET and PWRON
Hi Vikram,

On Thu, Feb 28, 2013 at 3:01 PM, Vikram Godbole
<vikram.godbole@gmail.com> wrote:
>
> Hi all,
>
> Questions regarding these two signals have come up occasionally in the past
> (for example:
> http://gumstix.8.n6.nabble.com/Interface-signal-questions-for-Overo-COM-boards-td659435.html),
> but (at least to my knowledge) have never been adequately resolved.
>
> 1. N_MANUAL_RESET:
>
> Per the latest Overo signals document, this is connected to OMAP ball AH25,
> which, according to the DM3730 datasheet, is sys_nrespwron. On the Chestnut
> board, this is connected to ground via a pushbutton switch. Now the TPS65950
> Design-In Guide
>
> http://www.ti.com/lit/ug/swcu056c/swcu056c.pdf
>
> explicitly cautions against using nrespwron for resetting the system. From
> Section 4.3.1.4 (Resetting the System):
>
> "NRESPWRON is an output from TPS65950 that at initial power-on de-asserts
> and takes OMAP out of reset. This reset must not be used to reset OMAP
> asynchronously. If an external circuit is used to assert NRESPWRON to reset
> OMAP, then this assertion causes OMAP to reset and it may cause the platform
> to be unstable."
>
> "To avoid the above behavior it is recommended that OMAP and TPS65950 be
> reset using the warm reset feature on both devices. OMAP warm reset can be
> configured as an input. If external logic drives the warm reset low on both
> OMAP and TPS65950, then both devices would be reset without abnormal
> behavior."
>
>
> Is this a bug on the Gumstix COMs? Could use of N_MANUAL_RESET cause
> possible stability problems because it has been connected to sys_nrespwron?
> Or is it in fact connected to NRESWARM/sys_nreswarm and it is the Gumstix
> documentation that is incorrect? 
Yes---the N_MANUAL_RESET signal does connect to the sys_nrespwron
signal on the OMAP but doesn't directly drive the PMIC signal.  The
processor TRM indicated nrespwron is a valid reset source but driving
the nrespwron output directly on the PMIC would be bad.
The beagleboard schematic follows the same pattern.
>
>
> 2. PWRON:
>
> This is not used anywhere on the Chestnut board. For a battery-operated
> device, would it be sufficient to add a switch to ground on this, to start
> the system? Is PWRON pulled up to VBAT on the COM module?
The POWERON line (J1.65) is connected to the PWRON signal on the PMIC
and is pulled-up within the Overo COM.  It can be used as a system
start or stop event.

--Ash