By writing to bit  of the PRCR, the debugger asserts the DBGNOPWRDWN output. The expected usage model of this signal is that it is connected to the system power controller and that, when HIGH, it indicates that this controller can work in emulate mode.
If on a power-down request from the processor, the power controller is in emulate mode. It does not remove core or ETM power but, otherwise, it behaves exactly the same as in normal mode.
Emulating power down is ideal for debugging applications running on top of operating systems that are free of errors because the debug register settings are not lost on a power-down event. However, there are a number of disadvantages such as:
nIRQ and nFIQ interrupts to the processor must be externally masked as part of the emulation to prevent them from retiring the WFI instruction from the pipeline.
The reset controller must also be aware of this emulate mode to assert ARESETn on power up, rather than nPORESET. Asserting nPORESET on power up clears the debug registers inside the core power domain.
The timing effects of power down and voltage stabilization are not factored in the power-down emulation. This is the case for systems with voltage recovery controlled by a closed loop system that monitors the core supply voltage, rather than a fixed timed for voltage recovery.
State lost during power down is not modeled by the emulation, making it possible to miss errors in the state storage and recovery routines.
Attaching the debugger for a post-mortem debug session is not possible because setting the DBGNOPWRDWN signal to 1 might not cause the processor to power up. The effect of setting DBGNOPWRDWN to 1 when the processor is already powered down is implementation-defined, and is up to the system designer.