On connection to a target, the debugger shows the current state of the processor. Because of the way that the architecture is configured, the processor is probably just coming out of reset in Secure EL3 when you halt the debugger. However, your SoC might not do this.
We will now describe some common states that the target might be in upon connection:
Core or processor is powered down
Some targets contain hardware elements (for example switches), firmware, boot code, or an OS that power down certain cores or processors unless steps are taken. Also, cores or processors that are not being used for execution, or that have not been used recently, may be powered down by the power controller or OS of the SoC.
Processors contain hardware called debug probe, which allows you to see and configure the debug setup and operation for the processor. Because the debug probe and the processor logic are usually in different power domains, the processor logic might be powered up, while the debug probe is powered down.
Some debuggers cannot connect to powered down logic. If a debugger connection is successful, you probably cannot do much with the debugger until the core, processor, or debug probe is powered up.
Core or processor is held in reset
Some targets contain hardware elements, firmware or boot code that hold a core or processor in reset unless steps are taken. Also, some SoCs contain a reset controller or processor that must be configured to release another core or processor from reset.
Some debuggers cannot connect to cores or processors that are held in reset. If a connection is successful, debug probe cannot be performed until the core or processor is released from reset.
Core or processor is in a different security state
An Armv8-A architecture processor or core can have two security states, Secure state and Non-secure state. If the Secure state is implemented, privileged or secret information for the SoC is stored or handled via the Secure state. This means that, after a certain point in the development cycle of an SoC, the hardware or software will lock untrusted users out of the Secure state. This step is taken to prevent access to the protected data in the Secure state.
This diagram shows hardware or software locking a user out of the Secure state:
If you try to connect a debugger to an SoC that uses this operational model, then the debugger will only allow you to connect to the Non-secure state.
Core or processor is in a different Exception level
There are two common reasons why EL3 is not entered when connecting a debugger to a target.
The first reason is that the Exception level is not implemented.
In the Armv8-A architecture, certain Exception levels are optional. In some Armv8-A processor or core implementations, an Exception level is not accessible because it is not present in the design.
This diagram shows a design in which EL3 and EL2 are not implemented:
If you connected a debugger to an SoC that uses this operational model, you can only debug Exception levels EL1 and EL0.
The second reason why EL3 is not entered when connecting a debugger to a target is that the hardware or software locks users out of an Exception level.
SoC designs can lock users out of certain Exception levels either through hardware or software. This locking usually occurs late in the development cycle of the SoC, so that unprivileged users cannot access aspects of the code or SoC design.
This diagram shows an SoC in which EL3, which is usually where the secure monitor and firmware reside, is locked:
If you connected a debugger to an SoC that uses this operational model, then you could debug EL2, EL1 and EL0, but not EL3.