Power, Reset, and Clock Management
Each reset source is specified as being a cold or warm type. Cold types are synonymous with power-on-
reset (POR) types. Such sources are applied globally within each receiving entity (i.e., sub-system,
module, macro-cell) upon assertion. Cold reset events include: device power-up, power-domain power-up,
and eFuse programming failures.
Warm reset types are not necessarily applied globally within each receiving entity. A module may use a
warm reset to reset a subset of its logic. This is often done to speed-up reset recovery time, i.e., the time
to transition to a safe operating state, compared to the time required upon receipt of a cold reset. Warm
reset events include: software initiated per power-domain, watch-dog time-out, externally triggered, and
emulation initiated.
Reset sources, warm or cold types, intended for device-wide effect are classified as global sources. Reset
sources intended for regional effect are classified as local sources.
Each Reset Manager provides two reset outputs. One is a cold reset generated from the group of global
and local cold reset sources it receives. The other is a warm+cold reset generated from the combined
groups of, global and local, cold and warm reset sources it receives.
The Reset Manager asserts one, or both, of its reset outputs asynchronously upon reset source assertion.
Reset deassertion is extended beyond the time the source gets de-asserted. The reset manager will then
extend the active period of the reset outputs beyond the release of the reset source, according to the
PRCM’s internal constraints and device’s constraints. Some reset durations can be software-configured.
Most (but not all) reset sources are logged by PRCM’s reset status registers. The same reset output can
generally be activated by several reset sources and the same reset source can generally activate several
reset outputs. All the reset signals output of the PRCM are active low. Several conventions are used in
this document for signal and port names. They include:
•
"_RST" in a signal or port name is used to denote reset signal.
•
"_PWRON_RST" in a signal or port name is used to denote a cold reset source
8.1.7.3
Global Power On Reset (Cold Reset)
There are several cold reset sources. See
for a summary of the different reset sources.
8.1.7.3.1 Power On Reset (PORz)
The source of power on reset is PORz signal on the device. Everything on device is reset with assertion of
power on reset. This reset is non-blockable. PORz can be driven by external power management devices
or power supervisor circuitry. During power-up, when power supplies to the device are ramping up, PORz
needs to be driven Low. When the ramp-up is complete and supplies reach their steady-state values,
PORz need to be driven High. During normal operation when any of the device power supplies are turned
OFF, PORz must be driven Low.
8.1.7.3.2 PORz Sequence
•
PORz pin at chip boundary gets asserted (goes low). Note: The state of nRESETIN_OUT during
PORz assertion should be a don’t care, it should not affect PORz (only implication is if they are both
asserted and nRESETIN_OUT is deasserted after PORz you will get re-latching of boot config pins
and may see warm nRESETIN_OUT flag set in PRCM versus POR).
•
All IOs will go to a known state, as defined in the device datasheet, AM335x ARM Cortex-A8
Microprocessors (MPUs) (literature number
)
•
When power comes-up, PORz value will propagate to the PRCM.
•
PRCM will fan out reset to the complete chip and all logic which uses async reset will get reset.
nRESETIN_OUT will go low to indicate reset-in-progress.
•
External clocks will start toggling and PRCM will propagate these clocks to the chip keeping PLLs in
bypass mode.
•
All logic using sync reset will get reset.
•
When power and clocks to the chip are stable, PORz must be de-asserted.
•
Boot configuration pins are latched upon de-assertion of PORz pin
•
IO cell controls from IPs for all the IOs with a few exceptions (see datasheet for details) are driven by
536
Power, Reset, and Clock Management (PRCM)
SPRUH73H – October 2011 – Revised April 2013
Copyright © 2011–2013, Texas Instruments Incorporated