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!


On Sat, Mar 2, 2013 at 10:04 AM, <> wrote:

---------- Forwarded message ----------
From: Ash Charles <>
To: "General mailing list for gumstix users." <>
Date: Fri, 1 Mar 2013 22:23:00 -0800
Re: [Gumstix-users]
Hi Vikram,

On Thu, Feb 28, 2013 at 3:01 PM, Vikram Godbole
<> wrote:
> Hi all,
> Questions regarding these two signals have come up occasionally in the past
> (for example:
> but (at least to my knowledge) have never been adequately resolved.
> 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
> explicitly cautions against using nrespwron for resetting the system. From
> Section (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.