2.8.2 Debug access

The Debug element provides a DAP Bus input that connects to the following independent APs:

  • AHB-AP for CPU 0 debug access and certificate access.
  • AHB-AP for CPU 1 debug access.
  • APB-AP for System debug access.

An external DAP, such as the JTAG DAP, is required in the expansion subsystem to drive the Debug Access Interface.

Processor Debug Access

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.

System Debug Access

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:

  • System Debug ROM that describes all debug components in the Debug element accessible from this APB-AP. This includes a pointer to an external Expansion debug ROM at address location 0xF008_0000.
  • A trace funnel.
  • A Cross Trigger Interface that supports triggers to and from:

    • Timers and Watchdogs in the system to implement halt on trigger.
  • The Debug APB Expansion Interface allows customers to add extra Debug components to the system.

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.

Certificate Access

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 0x3000_0000 to 0x3000_1FFF 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:

  • If it is a request for information, the Secure boot code can write the requested data into the SRAM window before enabling read access for the debugger to the window by using CERTREADEN.
  • If the content is a certificate, after the certificate is checked, the processor can set CERTDISABLE to disable access from the debugger to this window. After CERTDISABLE is set to 1, the processor must check that the corresponding CERTDISABLED = 1, which indicates that the window is now closed, before continuing with the boot process.

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 CPU0 wakes, if the content of the SRAM window is a certificate, before it can proceed with any certification check or continue with the boot process, it must close the certification path by writing to the CERTDISABLE register and wait for the CERTDISABLED status to go to 1.
  • PD_SYS, PD_CPU0CORE, and PD_SRAM0 must remain in the ON state before CERTDISABLED = 1. This means that CPU0 must not enter WFI and SleepDeep state.
  • If a certification check is performed after closing the window, the processor must wipe the certificate 8KB window in SRAM before allowing software to execute from the SRAM window.
  • Before enabling read access, the content of the SRAM window must be wiped before it is used.
  • When using the certificate window, the Secure firmware or the debugger must not request a system Warm reset from any processor AIRCR register.

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:

  1. Pull and keep nSRST LOW to reset the SoC, and hold nSRST LOW to prevent the processors from booting.
  2. The debugger writes a pattern into the SRAM window to request information to be returned, which can be a request for this SoC ID.

    Note:

    Secure write is required.
  3. nSRST is deasserted, allowing the processor to boot.
  4. The processor boot code checks the SRAM window, and discovers the request.
  5. The processor wipes the content of SRAM window to all zeros.
  6. The processor writes the System or SoC identity data into the window followed by a flag to indicate that the data is ready.
  7. The processor writes to the control register (CERTREADEN) to enable SRAM window read access.
  8. The processor then enters an infinite loop or WFI with interrupts disabled. This halts the processor.
  9. The debugger polls the SRAM window area until the flag is set and then reads the identity data from SRAM.

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:

  1. The SoC is reset by pulling and keeping nSRST LOW, and nSRST is held LOW to prevent the processor cores from booting.
  2. The debugger then writes the certificate into the SRAM window.
  3. nSRST is deasserted, allowing the processor to boot.
  4. The processor boot code checks the SRAM window, and discovers the certificate.
  5. The processor closes the direct path to the window from the debugger by setting the CERTDISABLE register.
  6. The processor uses the certificate to perform debug configuration, for example, changing the life cycle state of the system or configuring the debug authentication signal values.
  7. The processor then continues its normal boot process.

Note:

This approach is designed primarily for certificate insertion or communication during and right after the assertion of nSRST. It is not designed to provide a mechanism for the debugger to do the same after boot or during normal execution.

Debug element clock and power control

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.

Non-ConfidentialPDF file icon PDF version101104_0200_00_en
Copyright © 2016–2018 Arm Limited or its affiliates. All rights reserved.