09.12.2012 Views

Cortex-A8 Technical Reference Manual - ARM Information Center

Cortex-A8 Technical Reference Manual - ARM Information Center

Cortex-A8 Technical Reference Manual - ARM Information Center

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

12.12.3 Detecting power down<br />

12.12.4 Operating system support<br />

Debug<br />

• The timing effects of power down and voltage stabilization are not factored in the<br />

power-down emulation. This is the case for systems with voltage recovery controlled by<br />

a closed loop system that monitors the core supply voltage, rather than a fixed timed for<br />

voltage recovery.<br />

• State lost during power down is not modeled by the emulation, making it possible to miss<br />

errors in the state storage and recovery routines.<br />

• Attaching the debugger for a post-mortem debug session is not possible because setting<br />

the DBGNOPWRDWN signal to 1 might not cause the processor to power up. The effect<br />

of setting DBGNOPWRDWN to 1 when the processor is already powered down is<br />

implementation-defined, and is up to the system designer.<br />

The processor enables the debugger to detect a power-down event occurrence so it can attempt<br />

to restore the debug session. Power-down events are detected by the following features:<br />

• While the core is powered down, accesses to debug registers return a slave-generated error<br />

response. See APB interface on page A-7 and Power down permission on page 12-10 for<br />

more information.<br />

• If the processor powers back up again before the debugger had a chance to access the APB<br />

interface, the debugger can still detect the occurrence of a power-down event. This is<br />

because the sticky power down status bit forces the processor to generate a<br />

slave-generated error response. See Device Power Down and Reset Status Register on<br />

page 12-36 for more details on the sticky power down bit.<br />

The OS Save and Restore Registers enable an operating system to save the debug registers<br />

before power down and to recover them after power up. The debugger and the debug monitor<br />

are prevented from accessing the debug registers from the time the OS starts saving the registers<br />

through power down, until they are restored after power up. This behavior minimizes the<br />

possibility of race conditions and therefore, increases the chances that the debug agent is able<br />

to resynchronize successfully after the OS completes the restore.<br />

Example 12-30 shows the sequence on power down of an operating system.<br />

Example 12-30 OS debug register save sequence<br />

; On entry, r0 points to a block of memory to save the debug registers.<br />

SaveDebugRegisters<br />

PUSH {r4, lr}<br />

MOV r4, r0 ; save pointer<br />

; Step 1. Set the OS Lock Access Register (OSLAR).<br />

BL GetDebugRegisterBase ; returns base in R0<br />

LDR r1, =0xC5ACCE55<br />

STR r1, [r0, 0x300] ; write OSLAR<br />

; Step 2. Get the number of words to save.<br />

LDR r1, [r0, 0x308] ; OSSRR returns size on first read<br />

; Step 3. Loop reading words from the OSSRR.<br />

1 LDR r2, [r0, 0x308] ; load a word of data<br />

STR r2, [r4], 4 ; push onto the save stack<br />

SUBS r1, r1, 1<br />

BNE%B1 ; loop<br />

; Step 4. Return the pointer to the first word not written and<br />

; leave the OSLAR set because no further changes are required.<br />

<strong>ARM</strong> DDI 0344K Copyright © 2006-2010 <strong>ARM</strong> Limited. All rights reserved. 12-87<br />

ID060510 Non-Confidential

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!