B.4 ARMv8 Debug UNPREDICTABLE behaviors

This section describes the behavior that the Cortex®‑A32 processor implements when:

  • A topic has multiple options.
  • The behavior differs from either or both of the Options and Preferences behaviors.

Note:

This section does not describe the behavior when a topic only has a single option and the processor implements the preferred behavior.

Table B-1 ARMv8 Debug unpredictable behaviors

Scenario Behavior
A32 BKPT instruction with condition code not AL

The processor implements the following preferred option:

  • Executed unconditionally.
Address match breakpoint match only on second halfword of an instruction The processor generates a breakpoint on the instruction, unless it is a breakpoint on the second half of the first 32-bit instruction. In this case the breakpoint is taken on the following instruction.
Address matching breakpoint on A32 instruction with DBGBCRn.BAS=1100

The processor implements the following option:

  • Does match.
Address match breakpoint match on T32 instruction at DBGBCRn+2 with DBGBCRn.BAS=1111

The processor implements the following option:

  • Does match.
Address mismatch breakpoint match on T32 instruction at DBGBCRn +2 with DBGBCRn.BAS=1111

The processor implements the following option:

  • Does match.
Other mismatch breakpoint matches any address in current mode and state

The processor implements the following option:

  • Immediate breakpoint debug event.
Mismatch breakpoint on branch to self

The processor implements the following option:

  • Instruction is stepped an unknown number of times, while it continues to branch to itself.
Link to non-existent breakpoint or breakpoint that is not context-aware

The processor implements the following option:

  • No Breakpoint or Watchpoint debug event is generated, and the LBN field of the linker reads unknown.
DBGWCRn_EL1.MASK!=00000 and DBGWCRn_EL1.BAS!=11111111

The processor behaves as indicated in the sole Preference:

  • DBGWCRn_EL1.BAS is ignored and treated as if 0x11111111.
Address-matching Vector catch on 32-bit T32 instruction at (vector-2)

The processor implements the following option:

  • Does match.
Address-matching Vector catch on 32-bit T32 instruction at (vector+2)

The processor implements the following option:

  • Does match.
Address-matching Vector catch and Breakpoint on same instruction

The processor implements the following option:

  • Report Breakpoint.
Address match breakpoint with DBGBCRn_EL1.BAS=0000

The processor implements the following option:

  • As if disabled.
DBGWCRn_EL1.BAS specifies a non-contiguous set of bytes within a double-word

The processor implements the following option:

  • A Watchpoint debug event is generated for each byte.
A32 HLT instruction with condition code not AL

The processor implements the following option:

  • Executed unconditionally.
Execute instruction at a given EL when the corresponding EDECCR bit is 1 and Halting is allowed

The processor behaves as follows:

  • Generates debug event and Halt no later than the instruction following the next Context Synchronization operation (CSO) excluding ISB instruction.
Unlinked Context matching and Address mismatch breakpoints taken to Abort mode

The processor implements the following option:

  • A Prefetch Abort debug exception is generated. Because the breakpoint is configured to generate a breakpoint at PL1, the instruction at the Prefetch Abort vector generates a Vector catch debug event.

Note:

The debug event is subject to the same constrained unpredictable behavior, therefore the Breakpoint debug event is repeatedly generated an unknown number of times.
Vector catch on Data or Prefetch abort, and taken to Abort mode

The processor implements the following option:

  • A Prefetch Abort debug exception is generated. If Vector catch is enabled on the Prefetch Abort vector, this generates a Vector catch debug event.

Note:

The debug event is subject to the same constrained unpredictable behavior, therefore the Breakpoint debug event is repeatedly generated an unknown number of times.
H > N or H = 0 at Non-secure EL1 and EL0, including value read from PMCR_EL0.N

The processor implements:

  • A simple implementation where all of HPMN[4:0] are implemented, and In Non-secure EL1 and EL0:

    • If H > N then M = N.
    • If H = 0 then M = 0.
H > N or H = 0: value read back in MDCR_EL2.HPMN

The processor implements:

  • A simple implementation where all of HPMN[4:0] are implemented and for reads of MDCR_EL2.HPMN, return H.
P ≥ M and P ≠ 31: reads and writes of PM XEVTYPER_EL0 and PMXEVCNTR_EL0

The processor implements:

  • A simple implementation where all of SEL[4:0] are implemented, and if P ≥ M and P ≠ 31 then the register is res0.
P ≥ M and P ≠ 31: value read in PMSELR_EL0.SEL

The processor implements:

  • A simple implementation where all of SEL[4:0] are implemented, and if P ≥ M and P ≠ 31 then the register is res0.
P = 31: reads and writes of PMXEVCNTR_EL0

The processor implements:

  • res0.
n ≥ M: Direct access to PMEVCNTRn_EL0 and PMEVTYPERn_EL0

The processor implements:

  • If n ≥ N, then the instruction is unallocated.
  • Otherwise if n ≥ M, then the register is res0.
Exiting Debug state while instruction issued through EDITR is in flight

The processor implements the following option:

  • The instruction completes in Debug state before executing the restart.
Using memory-access mode with a non-word-aligned address

The processor behaves as indicated in the sole Preference:

  • Does unaligned accesses, faulting if these are not permitted for the memory type.
Access to memory-mapped registers mapped to Normal memory

The processor behaves as indicated in the sole Preference:

  • The access is generated, and accesses might be repeated, gathered, split or resized, in accordance with the rules for Normal memory, meaning the effect is unpredictable.

Not word-sized accesses

The processor behaves as indicated in the sole Preference:

  • Reads occur and return unknown data.
  • Writes set the accessed register(s) to unknown.
External debug write to register that is being reset

The processor behaves as indicated in the sole Preference:

  • Takes reset value.
Accessing reserved debug registers

The processor deviates from Preferred behavior because the hardware cost to decode some of these addresses in debug power domain is significantly high:

Actual behavior:
  1. For reserved debug and Performance Monitors registers the response is constrained unpredictable Error or res0, when any of the following error instead of preferred res0 for reserved debug registers 0x000-0xCFC and reserved PMU registers 0x000-0xF00:

    Off
    Core power domain is either completely off, or in a low-power state where the Core power domain registers cannot be accessed.
    DLK
    DoubleLockStatus() is TRUE, OS double-lock is locked, that is, EDPRSR.DLK is 1.
    OSLK
    OSLSR_EL1.OSLK is1, OS lock is locked.
  2. In addition, for reserved debug registers in the address ranges 0x400 to 0x4FC and 0x800 to 0x8FC, the response is constrained unpredictable Error or res0 when the conditions in 1 do not apply and:

    EDAD
    AllowExternalDebugAccess() is FALSE, external debug access is disabled.
  3. For reserved Performance Monitor registers in the address ranges 0x000 to 0x0FC and 0x400 to 0x47C, the response is constrained unpredictable Error, or res0 when the conditions in 1 and 2 do not apply, and the following errors instead of preferred res0 for the these registers:

    EPMAD
    AllowExternalPMUAccess() is FALSE (external Performance Monitors access is disabled).
Clearing the clear-after-read EDPRSR bits when Core power domain is on, and DoubleLockStatus() is TRUE

The processor behaves as indicated in the sole Preference:

  • Bits are not cleared to zero.

Non-ConfidentialPDF file icon PDF versionARM 100241_0001_00_en
Copyright © 2016, 2017 ARM Limited or its affiliates. All rights reserved.