You copied the Doc URL to your clipboard.

Arm Cortex-A55 Core Technical Reference Manual : Armv8‑A Debug UNPREDICTABLE behaviors

Arm®v8‑A Debug UNPREDICTABLE behaviors

There are unpredictable behaviors associated with Debug.

The information in this section describes which option the Cortex®-A55 core implements based on the behavior.

Table A-1 Arm®v8‑A Debug unpredictable behaviors

Scenario Behavior
A32 BKPT instruction with condition code not AL

The core implements the following preferred option:

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

The core implements the following option:

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

The core implements the following option:

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

The core implements the following option:

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

The core implements the following option:

  • Option 2: Immediate breakpoint debug event.
Mismatch breakpoint on branch to self

The core implements the following option:

  • Option 2: 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 core implements the following option:

  • Option 1: 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 core 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 core implements the following option:

  • Option 1: Does match.
Address-matching Vector Catch on 32-bit T32 instruction at (vector+2)

The core implements the following option:

  • Option 1: Does match.
Address-matching Vector Catch and Breakpoint on same instruction

The core implements the following option:

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

The core implements the following option:

  • Option 1: As if disabled.
DBGWCRn_EL1.BAS specifies a non-contiguous set of bytes within a doubleword

The core implements the following option:

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

The core implements the following option:

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

The core 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 core implements the following option:

  • Option 2: 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 core implements the following option:

  • Option 2: 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 core 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 core 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 core 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 core 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 core implements:

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

The core 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 core implements the following option:

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

The core 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 core 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 or (AArch64 only) doubleword-sized accesses

The core 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 core behaves as indicated in the sole Preference:

  • Takes reset value.
Accessing reserved debug registers

The core 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:

    OffCore power domain is either completely off, or in a low-power state where the Core power domain registers cannot be accessed.
    DLKDoubleLockStatus() is TRUE, OS double-lock is locked, that is, EDPRSR.DLK is 1.
    OSLKOSLSR_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:

    EDADAllowExternalDebugAccess() 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:

    EPMADAllowExternalPMUAccess() 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 core behaves as indicated in the sole Preference:

  • Bits are not cleared to zero.

Was this page helpful? Yes No