|Home > Functional description > Debug element > Debug access|
The Debug element provides a DAP Bus input that connects to the following independent APs:
An external DAP, such as the JTAG DAP, is required in the expansion subsystem to drive the Debug Access Interface.
To provide Debug access to each processor, an AHB-AP is provided along with a single bit Granular Power Requester (GPR) to allow the debugger to request the processor to power up. A Debug ROM is also provided to point to both the internal Debug ROM of the processor and the GPR.
The GPR power request handshake signal connects to all PPUs in each CPU element to allow the debugger to request the processor to power up. The AHB-AP, for each processor, is always accessible regardless of the debug authentication settings. It is the Cortex®-M33 core that performs the task of gating access depending on the debug authentication signals settings.
All other debug logic in the Debug element is accessed by an APB-AP. The NIDEN debug authentication signal controls access to determine if debug is allowed.
Connected to the APB Debug are:
A Cross Trigger Interface that supports triggers to and from:
A Cross Trigger Matrix (CTM) is included in the Debug element so that all CTIs, including those in the processors and in the expansion subsystem, can trigger each other.
A timestamp must be provided from the expansion subsystem so that it can be used with other trace sources outside the subsystem.
The Debug element provides an access path from the Debug AHB Access Interface to enable it to write to an 8KB window. In SRAM 0, the window address location is
during initial system boot. This is a write-only path by default after Cold reset.
Read access to the same 8KB window can be enabled using a control register bit CERTREADEN, in the System control register block. The CERTDISABLE control register can disable this access port, thereby disabling access to this window.
This certification access piggybacks onto the CPU0 AHB-AP. Before using the certificate path, CPU0 must first be powered up using the CPU0 GPR controls which indirectly also wake the Base element.
This allows a debugger to deposit a debug certificate, or a request for data, into the memory location at boot while the processor is held off from booting by holding the nSRST reset request input LOW. If the debugger does not support nSRST, the firmware can add debugger wait cycles to allow the debug software to write the SOC ID request to memory before boot. It also provides time to write in the certificate.
When the processor is allowed to boot, the Secure boot code can then check if the content in memory is a certificate or a request:
A system that already has debug authentication signals all tied LOW by default, or with fuses, can override the debug authentication settings using the payload in a valid certificate to re-enable debug or Secure debug.
To generate the certificate, it might be necessary to use the read capability of the path to request information about the system. The following rules must be followed if using the certification path:
When CERTDISABLE is set to 1, it is not possible to later re-enable the certification path except by using Cold reset.
The following example sequence list events that a debugger can use to request identity information from the subsystem:
The following example lists a sequence of events that a debugger can use to provide a certificate to the subsystem that it has generated using the identity data:
The Debug element is primarily running on DEBUGSYSCLK, except for the ATB Trace bus, which uses the faster clock, DEBUGFCLK. After the Debug element is turned on, DEBUGSYSCLK and DEBUGFCLK are expected to start running.
The Debug element contains a Power Policy Unit (PPU) that oversees the sequencing of clock, resets, and power control. The software can force the PPU to turn the debug element ON or OFF. However, the main intended use is to configure the PPU to support Dynamic transition between ON and OFF, depending on PD_DEBUG Power Q-Channel interface. This interface is expected to be used by the external Debug Access Port (DAP) to request power to turn on. The interface is also for the expansion system to ensure that power is only removed when the expansion subsystem is ready for power down.
After the Debug subsystem is powered up and running, the Granular Power Requesters in the debug power domain can be used to wake each core. Waking a core indirectly also wakes the Base element power domain.